This is the mail archive of the
mailing list for the Cygwin project.
Re: Multithreaded accept/connect locks
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 28 Jun 2007 22:28:22 +0200
- Subject: Re: Multithreaded accept/connect locks
- References: <email@example.com>
- Reply-to: cygwin at cygwin dot com
On Jun 28 16:17, firstname.lastname@example.org 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 http://cygwin.com/snapshots/, 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html