Signal handling in Win32 GUI programs

Signal handling in Win32 GUI programs

[Andy Koppe]

Hi,

Is there something special about signal handling in Win32 GUI programs? 
With MinTTY, I'm finding that signals sent to it are only delivered when 
writing data to the child process (i.e. when you try to kill it, it 
stays open until a key is pressed).

I guess that's fair enough in as far as POSIX doesn't guarantee anything 
about signal delivery time, but the description in the user's guide does 
sound as if it should be fairly immediate:

"When a Cygwin process starts, the library starts a secondary thread for 
use in signal handling. This thread waits for Windows events used to 
pass signals to the process. When a process notices it has a signal, it 
scans its signal bitmask and handles the signal in the appropriate fashion."

Also, there's no such problem with rxvt, so is there anything obvious I 
might be doing wrong? Or are there any tricks, ideally not involving 
polling, that I should be using?

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Christopher Faylor]

On Sun, Jan 11, 2009 at 04:26:36PM +0000, Andy Koppe wrote:
> Is there something special about signal handling in Win32 GUI programs? 
> With MinTTY, I'm finding that signals sent to it are only delivered when 
> writing data to the child process (i.e. when you try to kill it, it stays 
> open until a key is pressed).

I don't know if this is what you are seeing but If you are blocked in a
Windows function like WaitMessage or WaitForSingleObject, the signal
will not be delivered until some random time after you leave the
function.  We used to try to interrupt blocking windows functions but it
caused too many unpredictable problems.

One way around this is to start a thread and wait for signals in that
thread.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Andy Koppe]

Christopher Faylor wrote:
> I don't know if this is what you are seeing but If you are blocked in a
> Windows function like WaitMessage or WaitForSingleObject, the signal
> will not be delivered until some random time after you leave the
> function.

Alright, that's what it is then.

> One way around this is to start a thread and wait for signals in that
> thread.

I've added a thread doing 'for (;;) pause();', but unfortunately that 
doesn't seem to do the trick. Do I need to go into Cygwin internals and 
wait directly on the Win32 event(s) used for signals?

Andy


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Christopher Faylor]

On Sun, Jan 11, 2009 at 04:57:02PM +0000, Andy Koppe wrote:
> Christopher Faylor wrote:
>> I don't know if this is what you are seeing but If you are blocked in a
>> Windows function like WaitMessage or WaitForSingleObject, the signal
>> will not be delivered until some random time after you leave the
>> function.
>
> Alright, that's what it is then.
>
>> One way around this is to start a thread and wait for signals in that
>> thread.
>
> I've added a thread doing 'for (;;) pause();', but unfortunately that 
> doesn't seem to do the trick. Do I need to go into Cygwin internals and 
> wait directly on the Win32 event(s) used for signals?

sigwait() will probably work better than pause.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Andy Koppe]

>> I've added a thread doing 'for (;;) pause();', but unfortunately that 
>> doesn't seem to do the trick. Do I need to go into Cygwin internals and 
>> wait directly on the Win32 event(s) used for signals?
> 
> sigwait() will probably work better than pause.

That indeed works, thank you very much! I didn't know that function, 
very handy. With that and threads, signal handlers with all their 
vagaries aren't really needed anymore, are they?

And speaking of threads, does it make a difference whether one uses 
Pthreads or Win32 threads? I mean apart from portability and the small 
overhead Pthreads presumably incur.

MinTTY's got three such little helper threads hanging about now, doing 
waitpid() on the child process, read() on the child pty, and the 
abovementioned sigwait(). Would there be any point in trying to 
consolidate them into a single sigwait() process, using SIGCHLD and 
asynchronous reads?

Andy


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Christopher Faylor]

On Sun, Jan 11, 2009 at 08:53:49PM +0000, Andy Koppe wrote:
>>>I've added a thread doing 'for (;;) pause();', but unfortunately that
>>>doesn't seem to do the trick.  Do I need to go into Cygwin internals
>>>and wait directly on the Win32 event(s) used for signals?
>>sigwait() will probably work better than pause.
>
>That indeed works, thank you very much! I didn't know that function,
>very handy.  With that and threads, signal handlers with all their
>vagaries aren't really needed anymore, are they?

I have it on my todo list to see why pause doesn't work.  I'd like to do
some signal revamping someday but I don't want to destabilize 1.7.0 to
do that.

>And speaking of threads, does it make a difference whether one uses
>Pthreads or Win32 threads?  I mean apart from portability and the small
>overhead Pthreads presumably incur.

You really have to use pthreads.  Using non-posix methods is always asking
for trouble in Cygwin.

>MinTTY's got three such little helper threads hanging about now, doing
>waitpid() on the child process, read() on the child pty, and the
>abovementioned sigwait().  Would there be any point in trying to
>consolidate them into a single sigwait() process, using SIGCHLD and
>asynchronous reads?

Hmm.  I guess you could just do a sigwait on SIGCHLD and consolidate the
signal handling with that.  I don't think it makes sense to set up async
I/O just to do reads on the pty.  That would eliminate one thread at
least.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Andy Koppe]

Actually I still can't quite get signal handling in MinTTY to work 
right. SIGINT is fine, but SIGTERM, SIGHUP, and SIGKILL don't seem to 
get to sigwait(), instead still invoking the default handler, i.e. 
terminating MinTTY without SIGHUP being sent to the command inside it.

Here's what I got:

   static const sigset_t term_sigs =
     1<<SIGHUP | 1<<SIGKILL | 1<<SIGTERM | 1<<SIGINT;

   static void *
   signal_thread(void *arg)
   {
     int sig;
     sigwait(&term_sigs, &sig);
     puts("signalled");
     if (pid)
       kill(pid, SIGHUP);
     exit(0);
   }

And in the main thread:

     pthread_sigmask(SIG_BLOCK, &term_sigs, 0);
     pthread_t thread;
     pthread_create(&thread, 0, signal_thread, 0);

Anything obvious missing?

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Chris January]

On Tue, Jan 13, 2009 at 7:29 AM, Andy Koppe wrote:
> Actually I still can't quite get signal handling in MinTTY to work right.
> SIGINT is fine, but SIGTERM, SIGHUP, and SIGKILL don't seem to get to
> sigwait(), instead still invoking the default handler, i.e. terminating
> MinTTY without SIGHUP being sent to the command inside it.

> Anything obvious missing?

Shouldn't pthread_sigmask be called for signal_thread as well?
From the Linux manual page:
"In a multithreaded program, the signal should be blocked in all
threads to prevent the signal being delivered to a thread other than
the one calling sigwaitinfo() or sigtimedwait()). "
But maybe that doesn't apply to Cygwin.

Chris

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Signal handling in Win32 GUI programs

[Andy Koppe]

2009/1/13 Andy Koppe <andy.koppe@gmail.com>:
>  static const sigset_t term_sigs =
>    1<<SIGHUP | 1<<SIGKILL | 1<<SIGTERM | 1<<SIGINT;

Seems this is the problem. It needs to be done the proper way, using sigaddset.

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/