> Similar with STDIN_FILENO fwiw. If you never enter any character you > simply hang forever waiting for input. > > So imho the way the program is written is buggy. Alas, nothing in the splice(2) man page prepared me for this (and I guess it is not an easy task to explain this limitation in there). I thought about ways to make it work, while still using splice, and taking into account the child execs an arbitrary binary, but could not come up with anything not overly complicated. I still hope this can be fixed in the kernel (by using some finer-grain locking maybe), but for now, I guess, Go's io.Copy should stop using sendfile if either file descriptor refers to a pipe. > But Jens might be able to provide more details. > > > > > To me, the code above looks valid, and the kernel behavior seems to > > be a bug. In particular, if the process is exiting, the pipe it was > > using is now being closed, and splice (or sendfile) should return. > > > > If this is not a kernel bug, then the code above is not correct; in > > this case, please suggest how to fix it. > > > > Regards, > > Kir. > > > > ---- > > [1]: https://github.com/opencontainers/runc > > [2]: https://github.com/opencontainers/runc/pull/4598 > > [3]: https://go-review.googlesource.com/c/go/+/603295
