RFC: Too many race conditions.
Tue May 22 15:17:00 GMT 2007
Andrew Haley wrote:
> David Daney writes:
> > The semantics of files and pipes change if you don't close them when the
> > application asks for them to be closed. In a pipe for example the read
> > side would block waiting for the EOF. For a file, the filesystem
> > containing the file could not be unmounted. Waiting for a potentially
> > blocking I/O operation to finish before closing could cause deadlock.
> Is it true that in such cases the current code would cause incorrect
> operation? That all we would be doing is, at worst, exchanging one
> sort of incorrect behaviour for another?
> > Also counting references requires obtaining some type of mutual
> > exclusion lock twice for each I/O operation.
> Atomic counters are easy enough to do.
Atomic counters would work for accept calls where we interrupt them
using shutdown. Where they fail is on something like a FileInputStream
attached to a device that can block (i.e. not a file but some character
driver), or a pipe. In this case you cannot defer the close because the
read will block. We really want the close to interrupt the read, but it
cannot if it is deferred. I suppose one could argue that
FileInputStream's semantics are only guaranteed for files where they
will never block, but I don't like it.
I think my tricky dup2 trick will work in all cases, so perhaps I will
work on a patch that does that. I think using a combination of dup2 to
close the resource reuse race while not changing the semantics of close
plus atomic counters to clean up the extra dummy file descriptors
created might be the winning solution.
More information about the Java