You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was labelled with: A-io, B-RFC in the Rust repository
libnative does not detect when a read/write fails due to O_NONBLOCK being set on the fd. It makes the assumption that all of its files never have that flag set, because it never sets that flag on them. Unfortunately, this isn't necessarily the case. FIFOs and character device files (e.g. terminals) will actually share the O_NONBLOCK flag among all processes that have the same open file description (e.g. the underlying kernel object that backs the fd).
Using a tiny C program that uses fcntl() to set O_NONBLOCK on its stdout, a FIFO, and a Rust program that writes 32k of output to stdout, I can reproduce this issue 100% of the time. The invocation looks like
> (./mknblock; ./rust_program) > fifo
and on the reading side I just do
> (sleep 1; cat) < fifo
This causes the rust program to return a "Resource temporarily unavailable" error from stdout.write() after writing 8k of output. Removing the call to ./mknblock restores the expected behavior where the rust program will block until the reading side has started consuming input. And further, switching the rust program over to libgreen also causes it to block even with ./mknblock.
Saturday Apr 05, 2014 at 07:13 GMT
For earlier discussion, see rust-lang/rust#13336
This issue was labelled with: A-io, B-RFC in the Rust repository
libnative does not detect when a read/write fails due to
O_NONBLOCK
being set on the fd. It makes the assumption that all of its files never have that flag set, because it never sets that flag on them. Unfortunately, this isn't necessarily the case. FIFOs and character device files (e.g. terminals) will actually share theO_NONBLOCK
flag among all processes that have the same open file description (e.g. the underlying kernel object that backs the fd).Using a tiny C program that uses
fcntl()
to setO_NONBLOCK
on its stdout, a FIFO, and a Rust program that writes 32k of output to stdout, I can reproduce this issue 100% of the time. The invocation looks likeand on the reading side I just do
This causes the rust program to return a "Resource temporarily unavailable" error from
stdout.write()
after writing 8k of output. Removing the call to./mknblock
restores the expected behavior where the rust program will block until the reading side has started consuming input. And further, switching the rust program over to libgreen also causes it to block even with./mknblock
.The C program looks like this:
The Rust program is a bit longer, mostly because it prints out information about stdout before it begins writing. It looks like this:
The text was updated successfully, but these errors were encountered: