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: SIGTERM does not stop backend postgres processes immediately




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 ?)...

A+O.

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


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