From:	newsham AT lava DOT net (Tim Newsham)
Subject:	Re: SIGKILL and blocking
15 Jun 1998 10:58:15 -0700 :
Message-ID:	<m0yld3p-0010wzC.cygnus.cygwin32.developers@malasada.lava.net>
References:	<199806151336 DOT JAA13520 AT kramden DOT cygnus DOT com>
Mime-Version:	1.0
To:	cgf AT cygnus DOT com (Christopher Faylor)
Cc:	cygwin32-developers AT cygnus DOT com

> Now that I answered your question, how about answering this one: Imagine
> that, instead of a pause() the program was doing a blocking socket
> operation that lasted at least 10 seconds.  What would happen when the
> SIGALRM occurred?

I believe this is already the case.  When a signal comes in, if there
is a handler, the handler just gets pushed on the stack.  The handler
doesnt get invoked until the (blocking) call completes.  It's only
when the handler is not set and the process should exit that WSACleanup
is called before pushing the do_exit address onto the stack.  This
forces (or is supposed to at least) the socket operation to stop early
and invoke the handler (always do_exit) in a timely manner.  

So,  if do_exit was called directly rather than using WSACleanup
and call_handler(), it would seem that the end result would be the
same as current behavior:  handlers wouldn't get run until blocking
calls complete, except for implicit exit handlers which would run
immediately.

> cgf

                                              Tim N.

- Raw text -