=== ----- Original Message ----- From: "Christopher Faylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 08, 2002 11:21 AM Subject: Re: CGF: please review my logic Re: bash/cmd CTRL-C problem...
> On Tue, Jan 08, 2002 at 11:15:11AM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" <[EMAIL PROTECTED]> > >> If you are looking for the "stub" code, it's in spawn_guts, around > >line > >> 1078 in the current sources. > > > >Line 1078 is the EOF for spawn.cc (current CVS). Is that correct? > > Sorry. Misread my vim output. Line 805. No probs. If I read the code correctly, it loops 100 times waiting for * the child to exit * a signal to the stub to arrive * the child to indicate it is a cygwin process (via the spr event) Is that correct? If so, then I see two things to consider: 1) Presumably the CTRL C is arriving via exceptions.cc:(ctrl_c_handler). If so, then IMO we can safely disable this handler once the child is spawned, because a) The child has it's own handler b) This process will terminate as soon as the child does, or the child indicates it's a cygwin process That may introduce a race (fork(), exec(), CTRL-C, child actually starts) - but that could be address'd via queueing the signals until the child shows it's a cygwin process. IMO this race isn't an issue - what do you think? Disabling it could be done via a flag for exceptions.cc in_spawn_stub - so the other types of keyboard interrupt will still be serviced. 2) After 100 signals are sent to the stub, it looks like it will terminate. Was there a problem with hanging stubs that caused a non-infinite loop? Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
