Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Date: Thu, 28 Nov 2002 21:00:12 -0500
From: Christopher Faylor <cgf-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: pipe performance problem
Message-ID: <20021129020012.GB9074@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <14936170000 DOT 20021127223905 AT huno DOT net> <20021127233624 DOT GK17798 AT redhat DOT com> <1245871093 DOT 20021128012046 AT huno DOT net> <20021128003443 DOT GD21457 AT redhat DOT com> <5549457171 DOT 20021128022032 AT huno DOT net> <6654089625 DOT 20021128033745 AT huno DOT net> <1988826218 DOT 20021128150740 AT huno DOT net> <14015247140 DOT 20021129012600 AT huno DOT net> <20021129003838 DOT GA8794 AT redhat DOT com> <10718265421 DOT 20021129021618 AT huno DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10718265421.20021129021618@huno.net>
User-Agent: Mutt/1.5.1i

On Fri, Nov 29, 2002 at 02:16:18AM +0100, thomas wrote:
>Christopher Faylor <cgf AT redhat DOT com> wrote:
>> You're aware that it is a major holiday in the US, right?  Guess what?
>> I'm in the US.  You shouldn't expect instant responses to your musings
>> even in the best of times but certainly not now.
>
>I'm sorry, I wasn't really aware of it.

How about the other part?  Like expecting answers within hours after you
send something?  Nothing to say there?  I guess you're just the impatient
type.

>>However, I'll go on record by saying that I haven't seen anything which
>>indicates that there is a bug in cygwin.  Hmm.  Sounds like something I
>>might have said before.
>
>Yes you did.  However i don't understand why you don't see this as a
>bug or even consider it a problem.  With all the tests and IMHO
>evidence i presented this really boggles my mind.  I'd honestly like to
>hear why you don't think cygwin is at fault here.

I'd honestly like to hear why you boggle at the concept that anyone
would point out the place where the 10ms delay occurs, and then, when
the 10ms delay was re-presented, say "Oh! That 10ms delay which I
pointed you at is a problem!"

>> If it is a problem with the 10ms delay in select.cc then I really don't
>> know how to solve it.  If you have ideas, you should post them.
>
>Now that's finally a statement on the issue.

I guess you're looking for a longer answer.  Let me take some of my
holiday time to present one.

ready_for_read is called for certain devices prior to actually reading
from the device.  It's purpose is to provide an interruptible method
for "blocking" prior to reading since cygwin's signals need to act like
UNIX signals and there is no real way to emulate signals on all flavors
of Windows with anything other than smoke and mirrors.

With pipes, the only way that I'm aware of to "block" in this fashion
is a poll loop where PeekNamedPipe is called to see if there is anything
available.  If there is nothing available then the poll loop will wait
for either 10ms or until a signal arrives.  If no signal arrives, the
loop continues, otherwise it exits.

In some (and only some) previous versions of cygwin, I had the bright
idea of avoiding the ready_for_read stuff when there were no signal
handlers in the program since I thought (erroneously) that signals would
either be ignored or terminate the program in this scenario.  Maybe this
is why a previous of cygwin would work with cd writers.  I don't know.
However, it is not the case that the only thing that a signal can do is
either be ignored or cause the process to terminate.  A signal can also
cause the process to stop.  So, allowing a pipe to block in a ReadFile
means that the process cannot be stopped.  That's not allowable.

So, what you are calling a "problem" is undoubtedly one of the many
compromises that Cygwin has to make in the interests of UNIX
compatibility which, I believe, is what I have been maintaining all
along.

Of course, it is entirely possible that there is something wrong with
the logic in cygwin and that a pipe is waiting 10ms for every read or
something like that.  I don't know.  I don't see how that's possible
from the code in ready_for_read but it's certainly at least a
possibility.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/