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: Sat, 2 Sep 2000 00:19:35 +0400
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: Egor Duda <cygwin-developers AT sources DOT redhat DOT com>
Organization: DEO
X-Priority: 3 (Normal)
Message-ID: <1137440989.20000902001935@logos-m.ru>
To: Chris Faylor <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: sync with children problem
In-reply-To: <20000901160904.A29015@cygnus.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-Transfer-Encoding: 7bit

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

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

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19