X-Spam-Check-By: sourceware.org
Message-ID: <ba40711f0608020915i2ba8eb43i5838674828252131@mail.gmail.com>
Date: Wed, 2 Aug 2006 12:15:34 -0400
From: "Lev Bishop" <lev DOT bishop AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.20(0.156/4/2) pipe hangs, dos files
In-Reply-To: <44CF7953.8090808@netbauds.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060801141450 DOT 88222 DOT qmail AT web51109 DOT mail DOT yahoo DOT com> 	 <44CF7953 DOT 8090808 AT netbauds DOT net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 8/1/06, Darryl Miles  wrote:
> I am still interested in tackling the whole situation but I do need to
> be furnished with a testcase to work with.  I believe the original
> comeback by the group of users running "unison" should have insisted a
> testcase was produced by them to demonstrate the new breakage.

As I recall, the "group of users running unison" was the exact same
group as the group who developed the currently-commented-out code in
select.cc, so there wasn't any particular need for them to provide
themselves a test case....

I'm sure it's all explained in the mailing list archives. Basically,
the NtQueryInformationFile() gives back the amount of non-paged pool
used by the pipe, which is only the same thing as the amount of data
available to read in the case that there are no outstanding read()s on
the pipe. Otherwise, the commented-out code can cause a write()r to
deadlock any time the process at the other end of the pipe issues a
read() for more than a pipe buffer's worth of data. This is much worse
than the current situation, where a non-blocking write can
occasionally block, which in turn may cause (serious) performance
issues but rarely a total deadlock. (After all, cygwin is not an rtos
and there is allowed to have arbitrary delays at any point in the
code, without violating the posix semantics, so long as eventually the
write() *eventually* returns.)

L

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