This is the mail archive of the cygwin 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: Multithreaded accept/connect locks

On Jun 28 16:17, wrote:
> On Jun 27 19:08, Corinna Vinschen wrote:
> > Yes, that's the same problem.  From stracing the problem it appears
> > that the underlying problem is in WinSock.  connect returns with an
> > error 10036, WSAEINPROGRESS, because the other thread is at that
> > time executing a blocking socket call (accept).  The problem is
> > aggravated by the fact that the connect call in Cygwin is always
> > using non-blocking mode and WSAEINPROGRESS is also referring to a
> > connect which is still in progress and needs further handling.
> With the 's' option, my previous program blocked on select() instead
> of accept(), so connect() must also collide with select().

Yes, that's expected.

> > In CVS, the Cygwin socket code has been reworked a lot.  One
> > important change is that besides recv/send/connect also accept is
> > now implemented in non-blocking mode under the hood.  This has the
> > effect that the connect call should't be able to fail due to a
> > blocking accept in the same process.  If you try your application
> > against a recent snapshot from, your
> > test application will run as expected.
> I'd like to keep this in a standard Cygwin distribution if possible.

You'll have to live with the behaviour in 1.5.24 then for some time.
There won't be any bug fixing to 1.5.24 anymore.  The next version will
be a major, major, MAJOR update with lots of changes, not only in socket


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

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