eio_windows: fix anonymous pipes on Windows - #929
Conversation
|
Confirming it fails in CI too |
cc6fe8b to
56440f7
Compare
|
I'm going to layer the process spawnign PR over this one; I can't do a full test case for a failing pipe without another process! |
On Windows,an anonymous pipe cant be made non-blocking, so this call always failed with an ENOTSOCK for me. We now use a pool thread for blocking reads and writes.
56440f7 to
b66631a
Compare
talex5
left a comment
There was a problem hiding this comment.
This doesn't look right - how will cancellation work?
According to https://stackoverflow.com/questions/34504970/non-blocking-read-on-os-pipe-on-windows, Windows does support non-blocking reads on pipes:
SetNamedPipeHandleState doc allows to put anonymous pipe to non-blocking mode.
Also, we probably want the same check for blocking mode that's in eio_posix. There, we have e.g.
eio/lib_eio_posix/low_level.ml
Lines 67 to 70 in 318abba
But in eio_windows, the wait is unconditional:
eio/lib_eio_windows/low_level.ml
Lines 41 to 44 in 318abba
|
|
||
| open Eio.Std | ||
|
|
||
| let read_all flow = |
There was a problem hiding this comment.
We do have Eio.Flow.read_all.
There was a problem hiding this comment.
Need this expanded to put debug printfs in! Not actually tried cancellations in, will do next: I think I've found one potential weirdness which is that the pipe behaviour changes if I SSH in vs run at the machine directly! Windows is driving me mad, mad I tell you.
This is a testcase failing on my machine atm, so opening to check windows CI here as well (I'm struggling with Windows Redirection Guard nuking my ssh setup due to the use of symlinks in Flexlink!)