This is the mail archive of the cygwin@cygwin.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: broken CTRL-BREAK handling


> I don't think that that has ever been a stated goal for cygwin.

That would explain why it has been a non-issue for most folks.
The only product I've ever used on windows that relies no CTRL_BREAK
is Sun's JVM.  Oh, and then there's MKS Toolkit's ksh of course (no,
not the M word!).  Maybe there are other products out there that rely
on ctrl handler, but I suspect it would be rare due to the flakiness
of the console event handling model.  Maybe zsh, tcsh, etc?

> What would a program, ported from UNIX expect in this situation?  With
> your patch, I believe that it would just unceremoniously terminate with
> no way to handle cleanup other than to add windows-specific code for
> dealing with ctrl-break.

Agreed.  However, if CYGWIN=ttl is set they would be fine
since ctrl_c_handler is not en force with that configuration.
If they did not use CYGWIN=ttl and pressed CTRL-BREAK the default
handler provided by Win32 would kick in and terminate the program
as soon as your ctrl_c_handler returned FALSE.

Yet another argument indicating the crippled nature of the whole console
control handler CTRL_*_EVENT model.

Seems like the ideal situation, which I don't think the Win32 API
would let you do, would be:

1. inside ctrl_c_handler check if there is something other than the
   default CtrlHandler and your ctrl_c_handler.  This would definitely
   be the case for the JVM, but not for unix-ported apps.
2. if not, do a SIGTERM within ctrl_c_handler just like you do
   today.  Which means CTRL_BREAK == CTRL_C.
3. if so return FALSE in ctrl_c_handler if type==CTRL_BREAK_EVENT,
   that way the other app-specific control handler would still get
   called.

The Win32 does not have a GetConsoleCtrlHandler or
GetConsoleCtrlHandlers function, so #1 would not be possible
if I read the API docs correctly.

Stalemate.  You've probably thought this through already.

Anyway, given these limitations, it's probably better to live
with the evil you know rather than introduce an evil you
don't.

Yet another argument for withdrawing my CTRL_BREAK proposal.

Thanks, Troy


-----Original Message-----
From: Christopher Faylor [mailto:cgf@redhat.com]
Sent: Wednesday, July 18, 2001 10:56 AM
To: cygwin@cygwin.com
Subject: Re: broken CTRL-BREAK handling


On Wed, Jul 18, 2001 at 10:32:35AM -0600, Troy Noble wrote:
>Bottom line... that still feels broken to me if the intent is for
>cygwin (more specifically, the bash shell running with cygwin) to
>be able to launch/stop native win32 apps with the same semantics one
>has come to expect when running cmd shell.
>If that's not the goal, then it's a non-issue.

I don't think that that has ever been a stated goal for cygwin.

What would a program, ported from UNIX expect in this situation?  With
your patch, I believe that it would just unceremoniously terminate with
no way to handle cleanup other than to add windows-specific code for
dealing with ctrl-break.

cgf

--
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/

--
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/


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