Mail Archives: cygwin/2001/05/10/14:11:22
On Thu, May 10, 2001 at 12:36:28PM -0500, Fred Yankowski wrote:
>On Thu, May 10, 2001 at 12:31:02PM -0400, Christopher Faylor wrote:
>> Remember this?
>> >Unfortunately, blocking recv() calls are not interruptible on Windows.
>> >I'm not aware of any mechanism for allowing this.
>
>Some research led me to believe that closesocket() could unblock a
>Win32 recv() call.
>
>> What do you think a signal handler does? It would need to interrupt
>> a blocking recv() to work, wouldn't it?
>
>Are you saying that a blocking recv() _must_ never be interrupted,
I didn't say "must". I said "can't".
>even if a mechanism exists that would make that possible?
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:
"Hmm. I'm having problems with getting signals to interrupt a recv()
call. Chris says that recv calls can't be interrupted but someone else
says that closesocket works. So, I know! I'll use a *signal* to
interrupt the recv call and close the socket!"
Perhaps this would work if you used another thread but there is no
mechanism in cygwin for doing this currently and I really doubt that
closing a socket is the right solution for dealing with this problem.
>If so, what is the basis for that decision? The recv() specified by
>the Open Group [1] seems to allow for an EINTR error case.
I'll bet the the Open Group would imply that a signal does not close
a socket if you are blocked in a recv() call, too.
I don't know why you are getting the impression that I'm passing down
an edict. I'm always open to methods for getting Cygwin to work
more like UNIX. I don't see how closing the socket can achieve this
goal, even if you could make it work.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -