Mail Archives: cygwin/2001/05/10/17:55:36
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
- Raw text -