This is the mail archive of the cygwin-developers@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: sync with children problem


On Sat, Sep 02, 2000 at 12:19:35AM +0400, Egor Duda wrote:
>Hi!
>
>Saturday, 02 September, 2000 Chris Faylor cgf@cygnus.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@some.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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]