Mail Archives: cygwin/2002/01/07/19:43:42
===
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin AT cygwin DOT com>
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" <cgf AT redhat DOT com>
> >> 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/
- Raw text -