Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Fri, 1 Sep 2000 16:11:03 -0400
From: Chris Faylor <cgf AT cygnus DOT com>
To: cygwin developers <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: sync with children problem
Message-ID: <20000901161103.A29092@cygnus.com>
Reply-To: cygwin-developers AT sources DOT redhat DOT com
Mail-Followup-To: cygwin developers <cygwin-developers AT sources DOT redhat DOT com>
References: <1975989842 DOT 20000901235524 AT logos-m DOT ru> <20000901160904 DOT A29015 AT cygnus DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <20000901160904.A29015@cygnus.com>; from cgf@cygnus.com on Fri, Sep 01, 2000 at 04:09:04PM -0400

On Fri, Sep 01, 2000 at 04:09:04PM -0400, Chris Faylor wrote:
>On Fri, Sep 01, 2000 at 11:55:24PM +0400, Egor Duda wrote:
>>Hi!
>>
>>  i've  encountered  a  problem  with program doing fork-exec-waitpid,
>>namely  cvs  working  via  ssh.  the worst in situation is that when i
>>everything  run under strace, problem vanishes (and i guess this means
>>we've  got  some  race  here).  maybe child process exits too soon, or
>>something  like  that.  snapshot  taken  from  sourceware  ( DLL build
>>2000-08-25-23:55-EST)   shows  the  same  behavior.  currently,  as  a
>>workaround, i've applied this patch (that looks more like dirty hack),
>>just  to  make  things  work,  but i think that such change can likely
>>broke something else. any comments?
>
>Yep.  Sorry but the patch makes no sense.  The only effect of calling
>proc_can_be_signalled over your change would be to wait for the
>signal handler thread to call 'SetEvent (wait_sig_inited)' in the
>unpatched version.
>
>If that is never happening, then there is something seriously wrong
>somewhere.
>
>Do you have a simple test case for this scenario, even if it takes
>a bunch of repetitions to trigger?

Out of curiousity, does this change the behavior at all?

cgf

Index: sigproc.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/sigproc.cc,v
retrieving revision 1.32
diff -u -r1.32 sigproc.cc
--- sigproc.cc	2000/08/26 03:48:37	1.32
+++ sigproc.cc	2000/09/01 20:10:50
@@ -609,7 +610,7 @@
 void __stdcall
 sigproc_init ()
 {
-  wait_sig_inited = CreateEvent (&sec_none_nih, FALSE, FALSE, NULL);
+  wait_sig_inited = CreateEvent (&sec_none_nih, TRUE, FALSE, NULL);
   ProtectHandle (wait_sig_inited);
 
   /* local event signaled when main thread has been dispatched