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: bash/cmd CTRL-C problem...

----- Original Message -----
From: "Christopher Faylor" <>

> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
> >FWIW this patch (Chris where should I put the in_stub declaration)
> There is already an indicator that an execed process is running --
> hExeced, so I don't think you need the 'in_stub' thing.

No, hExeced is set far too early... There is a very narrow window where
we want to ignore CTRL-C.

> However, it seems to me that this solution is racy.  If a person types
> CTRL-C during process startup, it's possible that a cygwin process
> never see a true cygwin signal.  Hmm.  I guess this race is already
> in signal_exit, in fact.  I have to fix that.

Yes there is. I asked for thoughts, but got none :}. However, note the
requirements to drop the signal:
* The process startup must be in _P_OVERLAY mode.
* The new process must have successfully been created.
* Their must be no cygwin parent to the spawning process, or the
spawning process must be the top of the process group.
* The new process must not have signalled it's creation back to us.

> Regardless, it is not always the correct behavior for CTRL-C just do
> the "default thing".  If the execed process is supposed to be ignoring
> SIGINT then it isn't right for the process to exit.

Hangon, look closer.
If the execed process is a *cygwin* process, then my patch makes no
difference - the stub is about to quit no matter what, and from a POSIX
point of view, already has!
If the execed process is not a cygwin process, then it will handle (or
not) CTRL-C itself. We should *not* force quit it when the stub recieves
I don't reinstate default behaviour, we simply ignore the keyboard
generated CTRL-C which we know that the non-cygwin child has already

> Also, your change seems to make no distinction between a spawned and
> execed process.  It looks like if the user had called spawn, a CTRL-C
> would just cause the parent process to die.

No, if the user had called spawn, with mode != _P_OVERLAY, then this
patch makes no difference.
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
cygwin program then the user will notice no difference, or worst case a
_perfectly timed_ CTRL-C is ignored. (Note: Ctrl-Break is not altered).
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
non cygwin program then the user will notice no difference - the non
cygwin program will handle it's own CTRL-C.

Unsubscribe info:
Bug reporting:

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