SIGTERM does not stop backend postgres processes immediately

[Christopher Faylor]

On Thu, May 10, 2001 at 06:54:30PM +0200, Olivier Fambon wrote:
>Christopher Faylor wrote:
>> On Thu, May 10, 2001 at 11:26:39AM -0500, Fred Yankowski wrote:
>> >To unblock recv() on receipt of a signal -- SIGHUP in particular, for
>> >this test -- I set up a signal handler that calls close() on the
>> >socket fd.  It looks to me like this should call
>> >fhandler_socket::close() on that fd, which then calls closesocket() on
>> >the underlying Win32/winsock SOCKET, which is purported to unblock
>> >the Win32 recv() call on that socket.
>> 
>> Remember this?
>> >Unfortunately, blocking recv() calls are not interruptible on Windows.
>> >I'm not aware of any mechanism for allowing this.
>> 
>> What do you think a signal handler does?  It would need to interrupt
>> a blocking recv() to work, wouldn't it?
>
>I once did something similar to what Fred Yankowski did to 'unblock' a
>socket recv(). Same trick: close the socket to 'interrupt' the syscall.
>
>... But this was in a multi-threaded process, and I was sure that the
>'closing' thread would actually close the socket in the back of the
>'blocked' thread.
>
>He does the same, but the code does not get called (coz the handler is
>not executing in a thread ?)...

Right.  That is not how signal handlers work on UNIX and it is not how
signal handlers work under Cygwin.

Microsoft does start a new thread for dealing with things like SIGINT
but Cygwin redirects those signals to the main thread.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple