Comment 1:

Labels changed: added repo-main.

Comment 2:

Too late to make such a fundamental change.

Labels changed: added release-go1.5, removed release-go1.4.

If we do decide to add a rw mutex I've added the following CL that implements that in os.file https://go-review.googlesource.com/#/c/10186/

CL https://golang.org/cl/10186 mentions this issue.

Using an RWMutex for file.fd will mean that if a Read hangs in the kernel waiting for data, a Close on the same file will hang waiting for the read to complete. I don't think that is desirable.

I think we should postpone this until issue #6817 is fixed.

#6817 might help with this, but I'm not convinced it is always available in all cases. Maybe I'm wrong.

We might be able to just keep living with this. Certainly we don't hear about it much.

If we need to fix things, and AIO is not good enough (and I suspect it's not), one possibility would be to create an unusable fd somehow (for example call socket without binding it anywhere, or maybe call pipe and close the read end and use the write fd) and instead of using Close(fd) use Dup(badfd, fd). That would close the original fd and make f.fd unusable, without leaving the fd available for reuse immediately. The Dup'ed copy of badfd could be properly closed when we know all the i/o has stopped. The problem with this, I suspect, is that Close of a file open for writing can return information about write errors that are as yet unreported, and I suspect Dup onto an existing fd does not return those errors.

Like I said, this is very difficult to fix. I expect that most other languages just live with this the same as Go. I don't know that there's any fix that's not worse than the problem.

It would be nice to know what other languages do, if anyone knows.

I think it's worth noting that nothing in os.File documentation says its methods are safe to call from multiple goroutines. net.Conn has that guarantee, os.File does not.

I'm not really sure which languages permit concurrent read/close access in any way. I think for most languages it is undefined behavior. For kernel file descriptors it is permitted, but of course the same race is possible.

In the net package we handle the same problem with the code in net/fd_mutex.go. As far as I can see the same approach would work in the os package. This would mean extending the problem of errClosing (#4373) to the os package.

The fix for issue #6817 probably requires some set of helper threads for I/O. AIO is not really possible on GNU/Linux systems. There is no separate supported kernel interface for it; the aio_read functions and friends are implemented by simply using a thread pool for I/O.

Continuing my Dup comment from above, @aclements points out taht we can avoid losing the error from syscall.Close by doing:

newfd := syscall.Dup(fd)
syscall.Dup2(badfd, fd)
err := syscall.Close(newfd)
... close fd (now equivalent to badfd) once ref count drops to 0 ...

Of course, this would mean that if you run out of file descriptors, it becomes impossible to close a file. We could do this only for fd's with pending operations, of course, but then there's a little-exercised code path lurking.

This seems extremely low priority. Going to move to Unplanned until that changes.

CL https://golang.org/cl/41674 mentions this issue.

Change https://golang.org/cl/65490 mentions this issue: os/exec: remove protection against simultaneous Wait/Write

Change https://golang.org/cl/66150 mentions this issue: internal/poll: don't return from Close until descriptor is closed

Change https://golang.org/cl/83715 mentions this issue: net, os: don't wait for Close in blocking mode

Change https://golang.org/cl/83995 mentions this issue: os: don't wait for Close if the File was returned by NewFile