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: How to diagnose Cygwin / Windows shutdown problem

I don't know for sure either, but by the end of a day, it is not unusual for me to see multiple instances of bash.exe within my task manager, despite having closed them in windows. Therefore I don't think there is windows->posix signal translation, just the other way around.

Igor Pechtchanski wrote:

There is such a mechanism on Win2k.  I don't think there is one on Win9x.
This thread seems to indicate that there isn't one on WinXP, either, at
least not for shutdown messages.

On Wed, 23 Jul 2003, Andrew DeFaria wrote:

Randall R Schulz wrote:


Cygwin apps don't have a Windows event handler do they?

To tell you the truth... I don't know for sure.

The two programming models (Win32 and POSIX) are fundamentally
different, so based on my very limited understanding, it seems that
Cygwin itself (code in Cygwin1.dll) would have to intercept these
OS-generated events and translate them into POSIX signals (SIGUP, say).

Makes sense to me! I would suspect that when one clicks on the close
button in the window frame that generates a Windows event that is
translated somehow to send a kill signal to the shell. If true then
there is already a mechanism for Win Event -> POSIX signal.

Randall Schulz

At 17:16 2003-07-23, Andrew DeFaria wrote:

Randall R Schulz wrote:

Cygwin apps don't know about and cannot respond to the
system-generated messages that request that applications quit in
preparation for the system to shut down or the user to log off.

"Cannot respond to"? When a system-generated message that requests
that applications quit in preparation for the systme to shut down or
the user to log off why can Cygwin apps (in particular bash or other
shell) simply do what it would have done if TMOUT was just triggered?

TMOUT If set to a value greater than zero, TMOUT is treated
as the
default timeout for the read builtin. The select
command termi-
nates if input does not arrive after TMOUT seconds when
input is
coming from a terminal. In an interactive shell, the
value is
interpreted as the number of seconds to wait for
input after
issuing the primary prompt. Bash terminates after
waiting for
that number of seconds if input does not arrive.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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