Rewriting the FIFO code
Jameson Nash
vtjnash@gmail.com
Thu Jul 25 16:02:21 GMT 2024
I am hopping in late to this conversation, after working on debugging a
confusing issue where my NamedPipe stopped working reliably after being
passed to a cygwin program, where I believe it used to work okay with older
versions of cygwin. I just want to point out that the current flag being
used (Win32 calls it PIPE_NOWAIT) is documented as do-not-use (e.g.
https://devblogs.microsoft.com/oldnewthing/20110114-00/?p=11753) as it
interferes with the reliable execution of other programs that are using the
same pipe end, and that do not want to use the inefficient busy-wait
polling that cygwin's implementation does. As the documentation points out,
there is no way to recover correct behavior of OVERLAPPED while the flag is
enabled. By contrast, however, with PIPE_WAIT mode, it is possible to
implement non-blocking IO, including select, with OVERLAPPED operations, by
using ReadFile (with a size of 0) followed by PeekNamedPipe (if you want to
estimate the number of bytes to read) followed by a ReadFile of that number
of bytes (or an estimated number) followed by an immediate CancelIOEx (or
CancelIO on older platforms). I can post some example code from libuv if
that would be helpful? Removing this `PIPE_WAIT` change would eventually
also allow fixing the implementation of `select` in cygwin to actually use
event-driven notifications instead of emulating them with a slow loop as is
done now (https://cygwin.com/cygwin-ug-net/highlights.html).
Thanks!
-jameson
post note: I also wrote up some of this in
https://github.com/libuv/libuv/issues/4467 so that google hopefully indexes
it in case anyone manages to run across the same problem in nodejs and
searches for related issues, but I only wrote a few details there of how
libuv might be impacted by this, without the specifics of how cygwin could
be fixed
More information about the Cygwin
mailing list