This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interruptable connect


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]