delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/05/10/12:51:41

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3AFAC7C6.6576E069@inrialpes.fr>
Date: Thu, 10 May 2001 18:54:30 +0200
From: Olivier Fambon <Olivier DOT Fambon AT inrialpes DOT fr>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: SIGTERM does not stop backend postgres processes immediately
References: <E94FF01DFF6CD31186F4080009DC361502086B8D AT nttwr2 DOT tower DOT bldgs DOT butlermfg DOT org> <20010510112639 DOT A26981 AT enteract DOT com> <20010510123102 DOT B15024 AT redhat DOT com>


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019