This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: sigproc.cc (proc_subproc): make -j hang
- From: Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>
- To: cygwin-patches at cygwin dot com
- Date: Mon, 8 Mar 2004 16:18:14 -0500
- Subject: Re: sigproc.cc (proc_subproc): make -j hang
- References: <Pine.GSO.4.58.0403081435020.11361@thing1-200>
- Reply-to: cygwin-patches at cygwin dot com
On Mon, Mar 08, 2004 at 03:05:12PM -0600, Brian Ford wrote:
>While trying to analyze my own strace example of a "make -j hang" ala this
>ugly thread:
>
>http://www.cygwin.com/ml/cygwin/2004-03/msg00376.html
>
>My last strace output from the hung make process was:
> 69 1576822 [proc] make 6724 proc_subproc: pid 7524[0], reparented old
>hProcess 0x698, new 0x63C
>
>So, looking there, I stumbled onto the following:
>
>2004-03-08 Brian Ford <ford@vss.fsi.com>
>
> * sigproc.cc (proc_subproc): Only call sync_proc_subproc->release()
> once for exec().
>
>I'm not sure this is a bug, and it doesn't appear to fix the make hang I
>was looking at, but I thought it deserved a quick review by someone who
>knows that code :). Thanks.
While it probably shouldn't be doing what you discovered, the only effect
your fix should have is to bypass a no-op call to muto::release. Once a
muto has been released, calling release again should have no effect.
So, calling release twice should not be a problem. If this was truly a
problem then every exec would have a problem.
What seems to be happening in the CVS version of cygwin is that cygwin
routines are getting incorrectly interrupted during the function
execution instead of after the function returns.
cgf