Mail Archives: cygwin-developers/2003/02/25/13:06:42
On Tue, Feb 25, 2003 at 03:32:08PM +0100, Corinna Vinschen wrote:
> On Tue, Feb 25, 2003 at 03:18:55PM +0100, Corinna Vinschen wrote:
> > On Tue, Feb 25, 2003 at 02:53:41PM +0100, Thomas Pfaff wrote:
> > > SO_ERROR seems to be difficult because setsockopt does not allow to set
> > > it (and i don't know which error should be set after an interrupted
> > > connect. Maybe you could check this on Linux).
> >
> > I don't think SO_ERROR hurts badly. We could memorize the error code
> > WSAEINTR (which should be the correct error code on an interrupted
> > call) up to the next application call to Cygwin's getsockopt(SO_ERROR).
> > In Cygwin's getsockopt() we can call the WinSock getsockopt and if that
> > returns an error value of 0, we return the old error code instead and
> ^^^^^^^^^^^^^^^^^^
> WSAEINTR, that is.
>
> Corinna
>
> > set it to 0. Otherwise we just return the new error code. From then on,
> > back to normal.
Btw. Thomas, do you have the Stevens book "UNIX Network Programming"?
The end of chapter 15.5 contains the sub chapter "Interrupted connect"
which states
What happens if our call to connect on a normal blocking socket is
interrupted, say, by a caught signal, before TCP's three-way handshake
completes? Assuming the connect is not automatically restarted, it
returns EINTR. But we cannot call connect again to wait for the
connect to complete. Doing so will return EADDRINUSE.
What we must do in this scenario is call select, just as we have done
in this section for a nonblocking connect. Then select returns when
the connection completes successfully (making the socket writable) or
when the connection fails (making the socket readable and writable).
So, IIUC, connect isn't supposed to stop the TCP layer further trying
to connect! Which means, I hope, appropriately screwing your accept()
code into connect() in fhandler_socket.cc should be completely sufficient
to solve our problem.
Or do I miss something here?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -