On Fri, 4 Apr 2025 16:17:21 +0200 (CEST)
Johannes Schindelin wrote:
> Hi Takashi,
>
> On Fri, 4 Apr 2025, Takashi Yano wrote:
>
> > On Fri, 4 Apr 2025 14:13:57 +0200 (CEST)
> > Johannes Schindelin wrote:
> > > On Fri, 4 Apr 2025, Takashi Yano wrote:
> > > > On Fri, 04 Apr 2025 07:27:09 +0200 Johannes Schindelin wrote:
> > > >
> > > > > Is Jeremy's guess "if raw_write doesn't need to wait (ie, there's room
> > > > > in the pipe for the write) it doesn't hit the signal stuff" correct?
> > > > > If so, it would be good to add that part to the commit message because
> > > > > the commit would otherwise still be incomplete.
> > > >
> > > > That's not correct. Indeed, raw_write() waits for room in the pipe,
> > > > however, it does not matter in this case. The probelm occurs at
> > > > cygwait() which waits for pipe mutex as already mentioned in the commit
> > > > message.
> > >
> > > So what is the explanation, then, that this hung only occasionally and not
> > > all the time?
> >
> > As far as I investigated, the event handle signal_arrived was never
> > initialized all the time. Therefore, the its value is just copied from
> > the parent. The event signal_arrived is not inheritable, so, the handle
> > value is basically not a valid one.
>
> But that means that the `signal_arrived` that is copied from the parent
> process should be invalidated in the child processes, right?
Yes.
The 'value' of the handle is copied by child_copy() because the process
is forked, however, the handle itslef is not validated because the handle
is created by:
signal_arrived = CreateEvent (NULL, false, false, NULL);
(i.e. lpEventAttributes is NULL)
[in, optional] lpEventAttributes
A pointer to a SECURITY_ATTRIBUTES structure. If this parameter is NULL,
the handle cannot be inherited by child processes.
> Again, good material for the commit message, so that others do not have to
> repeat your analysis in its entirety.
OK.
--
Takashi Yano <takashi.y...@nifty.ne.jp>
