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
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Fri, 1 Sep 2000 16:32:48 -0400
To: Chris Faylor <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: sync with children problem
Message-ID: <20000901163248.A29171@cygnus.com>
Reply-To: cygwin-developers AT sources DOT redhat DOT com
Mail-Followup-To: Chris Faylor <cygwin-developers AT sources DOT redhat DOT com>
References: <1975989842 DOT 20000901235524 AT logos-m DOT ru> <20000901160904 DOT A29015 AT cygnus DOT com> <1137440989 DOT 20000902001935 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <1137440989.20000902001935@logos-m.ru>; from deo@logos-m.ru on Sat, Sep 02, 2000 at 12:19:35AM +0400

On Sat, Sep 02, 2000 at 12:19:35AM +0400, Egor Duda wrote:
>Hi!
>
>Saturday, 02 September, 2000 Chris Faylor cgf AT cygnus DOT com wrote:
>
>>>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?
>
>CF> Yep.  Sorry but the patch makes no sense.  The only effect of calling
>CF> proc_can_be_signalled over your change would be to wait for the
>CF> signal handler thread to call 'SetEvent (wait_sig_inited)' in the
>CF> unpatched version.
>
>i've   reproduced   this   under   gdb   and   see   that  if  i  call
>proc_can_be_signalled  it  won't  do  wait_for_me() but skip to

If it's not calling wait_for_me() then why is it hanging?

>return ISSTATE(..), and process_state is zombie.
>
>CF> If that is never happening, then there is something seriously wrong
>CF> somewhere.
>
>CF> Do you have a simple test case for this scenario, even if it takes
>CF> a bunch of repetitions to trigger?
>
>export CVS_RSH=/usr/local/bin/ssh1
>export CVSROOT=:ext:cgf AT some DOT server:/some/path/
>cvs co module
>cvs status file_in_module
>
>since  i have my cvs tree already pulled, i use only last command, but
>i presume you'll see "no children" diagnostics at checkout

"simple test case" == "some minimal number of c instructions demonstrating
the behavior".

cgf