Date: Thu, 15 Jun 2006 01:14:03 -0700
From: clayne AT anodized DOT com
To: cygwin AT cygwin DOT com
Subject: Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
Message-ID: <20060615081403.GA4457@ns1.anodized.com>
References: <20060519024910 DOT GA32309 AT ns1 DOT anodized DOT com> <20060614204025 DOT GY16683 AT calimero DOT vinschen DOT de> <20060615023024 DOT GA3872 AT ns1 DOT anodized DOT com> <20060615075840 DOT GA10596 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060615075840.GA10596@calimero.vinschen.de>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Thu, Jun 15, 2006 at 09:58:40AM +0200, Corinna Vinschen wrote:
> > 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

Actually the behaviour I'm noticing is within the same calling thread.
For instance, in almost all of my network functions I'm passing an fd and
using that fd with select to handle timeouts (connect/read/write all NB). So
in each case the same calling thread is doing the typical sequence: socket ->
connect -> write -> read -> close. The fd returned by socket() is never used
outside of that thread. So instead of a single thread w/ a single select and
iterating over multiple fds, post-select(), I have a thread pool with only
one fd-used-at-once-per-thread but multiple threads executing concurrently.

When a seperate fd entirely exhibits a read() timeout, it appears to affect
read/write in all other threads using different fds. Basically, as long as
data is flowing in all threads, there is no issue - but the second any one
fd stalls in any given thread - they all stall until I close that fd after
read() times out (where select() is indicating the timeout).

You can see the implementation of these network functions in the original
test case. I basically have a thread pool with each thread calling those
functions in the same order socket, connect, write, read, close.

-cl

--
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/