listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Jun 15 08:14:00 GMT 2006


On Jun 14 19:30, clayne@anodized.com wrote:
> On Wed, Jun 14, 2006 at 10:40:25PM +0200, Corinna Vinschen wrote:
> > 
> > Thanks very much for your testcase.  I applied a patch to Cygwin, please
> > give the next developer snapshot from http://cygwin.com/snapshots/ a try.
> > 
> > Corinna
> 
> Thank you Corinna. This appears to work much better and expected. BTW: I think
> the same issue may also exist for both read() and write() and possibly any other
> read, write, send, recv variant when using multiple threads as opposed to single
> thread + select(). One thing I notice is that if a read() is in progress and one
> is currently sitting in select(), all other read()s in seperate select()s will
> then stall if the former read() times out or takes longer than expected.

Your observation is correct, the same issue exists for recv/send and,
FWIW, connect.  I can fix the connect case, too, but there is no easy
patch for the recv/send case, unfortunately.  This has to do with the
way WSAEventSelect is handled in WinSock.

For now, if you want concurrency, either use non-blocking recv/send
exclusively, or never spread handling of the same blocking socket over
multiple threads.  Hopefully I can come up with a solution for this
problem at one point.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list