Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.2.20021128182739.00fdfa00@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Thu, 28 Nov 2002 18:45:18 -0800 To: cygwin AT cygwin DOT com From: Randall R Schulz Subject: Re: pipe performance problem In-Reply-To: <20021129020012.GB9074@redhat.com> References: <10718265421 DOT 20021129021618 AT huno DOT net> <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"; format=flowed Chris, At 18:00 2002-11-28, you wrote: >... > >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. That's what I told Thomas off-list, in a very generic form. >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. So, one could argue for a switch or mode or option of some sort. A "high-throughput-pipes" option that would disable this POSIX signal conformance correction and return the code to approximately it's old form. It would be "caveat user" to enable this mode and would probably have to be a per-process flag. I don't really expect you to like this idea, since clearly it's a hack. You mentioned "... on all flavors of Windows ...", suggesting that there are better options on certain varieties of Windows, so another alternative, perhaps less onerous (perhaps not) would be to use whatever OS-specific facilities are available to adapt the code to the optimum performance possible for the OS on which Cygwin is running. >cgf Randall Schulz Mountain View, CA USA -- 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/