Re: RFC: Too many race conditions.

[David Daney <ddaney at avtrex dot com>]

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.

David Daney

David Daney