Date: Wed, 14 Jun 2006 19:30:24 -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: <20060615023024.GA3872@ns1.anodized.com>
References: <20060519024910 DOT GA32309 AT ns1 DOT anodized DOT com> <20060614204025 DOT GY16683 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060614204025.GY16683@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 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.

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