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
Date: Thu, 10 May 2001 17:53:04 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Cc: fred AT ontosys DOT com
Subject: Re: SIGTERM does not stop backend postgres processes immediately
Message-ID: <20010510175304.A19397@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com, fred AT ontosys DOT com
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> <20010510123628 DOT A48047 AT enteract DOT com> <20010510140721 DOT F12136 AT redhat DOT com> <20010510155340 DOT A25542 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: <20010510155340.A25542@enteract.com>; from fred@ontosys.com on Thu, May 10, 2001 at 03:53:40PM -0500

On Thu, May 10, 2001 at 03:53:40PM -0500, Fred Yankowski wrote:
>On Thu, May 10, 2001 at 02:07:21PM -0400, Christopher Faylor wrote:
>> What mechanism is this?  You have already demonstrated that you can't
>> use Cygwin signals to interrupt a recv.  You seem to be using circular
>> reasoning:
>
>There are two 'recv()' APIs involved here:  the Win32/winsock one, and
>cygwin_recv() which is exported as recv() by the cygwin DLL.  Let's
>call them "recv(win32)" and "recv(cygwin)", respectively.  I haven't
>found a way to get an interrupt handler to run while recv(cygwin) is
>blocked, apparently because Cygwin code goes out of its way to prevent
>exactly that, deferring handler execution until recv(win32) unblocks.
>Because of that, I don't know if recv(win32) can be "interrupted" by
>calling closesocket().

The reason that Cygwin is "going out of its way" to avoid interrupting a
blocking call is BECAUSE IT DOESN'T WORK.

There are mechanisms for getting the appearance of interrupting a
blocking call.  We use some of these for normal I/O.

There may be mechanisms for doing something similar for recv.  I don't
know if there are or not.  There is no mechanism in Cygwin for
doing this currently, however.

Cygwin goes to great pains to avoid attempts to interrupt blocking
calls.  Trying to interrupt even non-blocking Windows calls via the
mechanmism that cygwin uses when code is executing outside of the dll
(SetThreadContext) can cause inexplicable hangs or system instability,
especially on Windows 9x.

>If an application signal handler was allowed to run while the process
>is blocked on recv(cygwin), at least the application would have some
>chance to react to the signal immediately.

You can't run the signal handler without interrupting the recv call.
Cygwin currently has no mechanism for interrupting a recv call.  There
is code in exceptions.cc which is used to interrupt the program when
it is not executing in the cygwin dll.  It won't work on blocking
windows functions.

>In a typical default Unix situation, I think this would result in the
>application call to recv() returning -1 with errno set to EINTR.

Yes, I know.  Cygwin is not doing this currently.

>It is hard to see how Cygwin could emulate this in the general case if
>closing the socket is the only way to unblock recv(win32).  But what's
>the harm in allowing signals to be handled while in recv(cygwin) even
>if recv(win32) remains blocked?

Wow.  There is really a communication breakdown here.  I keep telling
you that it is not possible to do what you want and you keep acting like
I'm making policy decisions which, if only I would relent, would solve
your problems.

Again, for hopefully the final time, there is no mechanism in Cygwin
currently for interrupting a blocking recv.  There are workarounds for
blocking reads on the console, on pipes, and on the serial port.  There
is no workaround for recv.

Right now,{ to "allow signals to be handled while in recv" would mean
that the recv would be interrupted.  It is probably possible to work
around this, but there is nothing in cygwin that would allow it.  So,
currently, there is no way to do what you are asking.  The code is not
making an arbitrary decision to avoid signals.  It is doing its best to
handle some unfortunate Windows behavior.  The Windows behavior for recv
has not been worked around, so recv blocks and there is no way around
that until workarounds similar to what is done for the console, ttys,
pipes, or serial code is done.

So, you are stuck, unless someone wants to contribute code.  I
may get to it sometime in the future but I make no guarantees.

cgf

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