This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: pipe performance problem
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/