pipe performance problem

[Randall R Schulz]

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/