Can somebody pinch me, please?

Corinna Vinschen
Fri Mar 11 18:14:00 GMT 2005

On Mar 11 19:19, egor duda wrote:
> Well, i guess i can try to remember why this code was added. Maybe i'm 
> misguided here. SUSv2 states on connect() that
> [...]
> I was probably assuming that there's some kind of "symmetry" between 
> connect() and accept() here. That is, when server accepts()s on 
> non-blocking socket and there's no inbound requests available it's still 
> possible that after some time client tries to connect() and will 
> succeed. At this time, it will need server-side secret event in place to 

The problem is that the non-blocking connect it's guranteed to succeed
if the server has called listen.  There's no need for the server to
call accept.  connect sends a SYN and returns EINPROGRESS.  According
to Stevens[1], BSD 4.4 repeats sending the SYN after 6 and after 24 seconds
and the connection timeout only happens after 75 seconds.  So a server
application has actually 75 seconds to call accept.  That's the crux
with non-blocking sockets.

However, that's not the usual case, especially for AF_LOCAL sockets
(knock on wood).  We can pretty savely assume that the usual non-blocking
server calls listen and then select.  So in 99.9% of the cases the server
is in select when the client calls connect.  The clients connect returns
EINPROGRESS, the server select wakes up and calls accept.  But in this
case, accept returns with a valid, connected socket and the secret event
and credential transactions should run fine.  It's a bit annoying that
both transactions result in some sort of synchronization and the non-
blocking connect degenerates to a blocking connect which nevertheless
returns EINPROGRESS, but I don't see how to workaround that.

Does that make sense?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
Red Hat, Inc.

More information about the Cygwin-developers mailing list