This is the mail archive of the 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]
Other format: [Raw text]

Re: CGF: please review my logic Re: bash/cmd CTRL-C problem...

----- Original Message -----
From: "Christopher Faylor" <>
To: <>
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" <>
> >> 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 (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
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 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?


Unsubscribe info:
Bug reporting:

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