Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 10 May 2001 12:31:02 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: SIGTERM does not stop backend postgres processes immediately Message-ID: <20010510123102.B15024@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20010510112639 DOT A26981 AT enteract DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <20010510112639.A26981@enteract.com>; from fred@ontosys.com on Thu, May 10, 2001 at 11:26:39AM -0500 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? cgf -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple