BrokenPipe sometimes not reported

[jorendorff]

Try piping this program's stdout to head. After the first 10 lines, head will exit. The pipe is now broken, so the next write should fail, and we should get thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)'

Instead, the Rust program keeps running indefinitely. GDB says SIGPIPE is "received" (but I guess ignored) by the process every time it tries to write.

Feels like a race condition: if you remove the sleep or just change it to be short, println! panics as expected.

// usage: ./yep | head
use std::time::Duration;
use std::thread::sleep;

fn main() {
    loop {
        println!("y");  // should panic after `head` exits
        sleep(Duration::new(0, 250_000_000));
    }
}

tested on Linux, rustc 1.15.0-nightly (0ed951993 2016-11-14)

[alexcrichton]

I believe what's happening here is in LineWriter::write. We detect that what's being written ("y\n") has newline in it and take the first branch. This write succeeds because the underlying primitive is buffered (e.g. BufWriter) but then when flush is next called we ignore the error and return that the bytes were written. If you let the program run long enough the buffer fills up and the error gets propagated through a call to write I believe.

Seems kinda weird to me to ignore that error, we should probably do something like this instead:

if n != i + 1 || { self.flush()?; true } {
    return Ok(n)
}

That is, propagate an error in flush if we wrote the entire line.

[alexcrichton]

Well... maybe not. So apparently this behavior changed in #32107 to fix #32085.

cc @Stebalien, thoughts?

[jorendorff]

Interesting. The new code doesn't satisfy the "write-xor-error guarantee" either, though. It does up to three operations on the underlying BufWriter, so of course the first can succeed and others can then fail. For example, line_writer.write(b"hello\n...1KB without newline...") could write hello\n successfully all the way through, then fail trying to write the rest.

Maybe the guarantee should be weakened to a reasonable-effort sort of thing. It's important in some systems-y cases where the user knows the type of the writer (e.g. a raw File being used as a transaction log). It doesn't seem valuable more generally, and I'd expect third-party impls of Write to break it more often than not.

[alexcrichton]

This also interacts with the documented semantics of Write::write which indicates

If an error is returned then no bytes in the buffer were written to this writer.

That's probably just an erroneous clause targeted at, for example, file descriptors. With buffered readers and writers (like a line writer) I think we fundamentally just can't uphold that guarantee.

Nominating for @rust-lang/libs discussion as I think we'll want to reword that documentation.

[jimblandy]

In some cases, write's caller is counting on the fact that an error means no bytes were written. For example, if an operation returns WouldBlock, the caller needs to know where to pick up writing again.

An abstract interface can't reasonably guarantee that any specific downstream source has received and acknowledged the data. On Unix, even if you do a write system call and it succeeds, the kernel might still be buffering the data, so you don't know if it's made it to disk or not. You have to do an fsync to find out whether it really made it.

But an abstract interface can and should be expected to let its user keep track of where it needs to continue its work, in the case of an intermittent error condition like WouldBlock.

[Stebalien]

If an error is returned then no bytes in the buffer were written to this writer.

That's probably just an erroneous clause targeted at, for example, file descriptors. With buffered readers and writers (like a line writer) I think we fundamentally just can't uphold that guarantee.

That clause is actually pretty important. Otherwise, you can't be sure of the state of a writer after it returns an error. For example, the following could would write "abc" twice if interrupted:

LineWriter::write_all("abc\ncde\n"); 

---

When I wrote that patch, I was thinking that the next write after a failed flush would error out but obviously didn't think it though. So, a simple fix would be to record that a flush didn't happen and try to flush before writing anything else (i.e., on the next call to write). Unfortunately, this does mean that writing a newline wouldn't guarantee a flush but I don't think there's much we can do about that at this point. I believe a PartialWrite error was discussed in the past but was rejected as it would make io::ErrorKind larger.

Alternatively, as we haven't actually written anything to the underlying file yet, LineWriter could just "undo" the write (either by reaching into BufWriter or re-implementing BufWriter).

[alexcrichton]

@jimblandy yeah it's definitely true that it's useful to have this guarantee, and it may just not be possible to relax the guarantee.

@Stebalien yeah on second though retrying the flush on the next write sounds like it'd be a good idea (at least for now). I think that we'll need to update LineWriter::write no matter what b/c the successfully written bytes are papered over with an error I think if the second write fails, right?

[Stebalien]

I think that we'll need to update LineWriter::write no matter what b/c the successfully written bytes are papered over with an error I think if the second write fails, right?

My point is to flush before doing anything else if the previous flush-on-newline failed. Only then do we write iff that flush succeeds. If the flush fails, return an error without writing anything (no papering over written bytes). However, the previously written bytes will not have been flushed so the documentation needs to be updated to say that we try to flush on newline but that flush may fail silently in some cases (and that the user should call Write::flush() to be absolutely sure).

[alexcrichton]

@Stebalien yeah that sounds good to me!

[jorendorff]

Since LineWriter and BufWriter are friends, I think it's possible to do this so that the first error is not ignored.

[alexcrichton]

Yeah that also seems reasonable to me, we could have LineWriter reach into internals if necessary.

[jimblandy]

Right, BufWriter is just an implementation detail of LineWriter, so if BW is not giving LW the information it needs, unless there's some more fundamental reason LW can't be implemented as specified, LW's implementation should just change.