This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
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/