Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Message-ID: <3AFAC7C6.6576E069@inrialpes.fr> Date: Thu, 10 May 2001 18:54:30 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: SIGTERM does not stop backend postgres processes immediately References: <20010510112639.A26981@enteract.com> <20010510123102.B15024@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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