This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]