This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: SIGCLD (?) problem
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-developers at cygwin dot com
- Date: Sun, 11 Aug 2002 15:23:01 -0400
- Subject: Re: SIGCLD (?) problem
- References: <016a01c24148$e61594e0$6132bc3e@BABEL>
- Reply-to: cygwin-developers at cygwin dot com
On Sun, Aug 11, 2002 at 04:08:06PM +0100, Conrad Scott wrote:
>So it looks (to the untrained eye) like a race, but I've not got
>anywhere much myself so I thought I'd punt on this one and hope
>some more wizardly being out there might see something in all
>this.
I don't see how there could be a race. thread 2 should be the
signal thread. It would be interesting to see what it is doing.
It sounds like it has not been started or something, which would
make the "wait_for_me" function block forever.
I've made some changes and added some assertions throughout the code.
I don't think they will solve the problem but it may make things a
little clearer if there is a problem.
>p.s. I'll keep this process hung in gdb for the moment in case I
>get enthusiastic tomorrow or someone else wants some more
>information.
Could you check on the value of wait_sig_inited? Is it non-zero?
The problem is that the process processing thread should not have
to be waiting for this. Although, it looks like it is possible
for this scenario to happen if a process forks, and then quickly
execs. My just-checked-in-changes change that behavior. So,
now if it hangs it should hang in fork.
cgf