In my testing, if I open a pipe in normal blocking mode, read from it in one thread, and then close it from another thread, the read is not interrupted. It simply hangs indefinitely. So as far as I can tell the situation you describe was broken before and it's broken now. I don't see how to fix it.

The GNU/Linux man page for close says

It is probably unwise to close file descriptors while they  may  be  in
use by system calls in other threads in the same process.  Since a file
descriptor may be reused, there are some obscure race  conditions  that
may cause unintended side effects.

While I think we can probably handle the race condition, that also suggests that closing a file does not interrupt any existing I/O on that file.

@ianlancetaylor thanks for feedback. What you say about traditional close semantic is also true for sockets. However the issue here was submitted with Go's net.Conn.Close semantic in mind where Close interrupts all currently blocking Read or Write. With recent generalization of runtime poller pipes should now be also handled in non-blocking / epoll mode so the question here really remains only about "regular" files - those that are rejected by epoll.

While it is tempting for me to say that like in #19586 (comment) IO on regular files should be alway really "non-blocking", and thus no cancellation is needed at all, I cannot ignore the fact of FUSE use case and when we already had deadlock where both server and client were tested as part of one process:

#19563 (comment)
https://groups.google.com/forum/#!msg/golang-nuts/11rdExWP6ac/UnP5P5m3VPEJ

With Close it can be a similar situation: Read request is made; a filesystem there really blocks somehow (NFS / FUSE / ...) but the syscall is handled via bocking way. If Close does not interrupt it - there is simply no way to cancel it.

I can imagine interrupting syscall from another P from Close via sending a signal. Offhand this should involve at least some synchronization via fdmu so that the signal is always processed before actual IO operation returns. I'm not sure such complications would be accepted though.

I don't think the deadlock mentioned above is possible here. The deadlock referenced was due to using RawSyscall rather than Syscall. That doesn't happen here.

I'm going to close this until we have a test case.