Races between close() and other operations on file channels

[Alan Bateman]

Florian Weimer wrote:
> What mechanisms prevent reuse of a file descriptor between the time it
> is extracted from a FileDescriptor object and the actual UNIX system
> call?  If there is any locking, it's not very apparent from the source
> code.
>   
There is a currently a problem in this area with file channels. Both 
file channels and selectable channels are interruptible channels and so 
must support asynchronous close. For the network oriented channels the 
mechanism used is a two-step process. An asynchronous close first dups 
the file descriptor in use by other threads to one used by the close 
mechanism (this other file descriptor is connected to one end of a half 
shutdown socket pair).  As the threads "complete" I/O then the last one 
releases the file descriptor. This mechanism has worked relatively well 
but was not originally implemented for file channels. A few months back 
I extended it to work with file channels but didn't get around to 
integrating the changes (mostly because Windows lacks the APIs in this 
area and the solution for that platform needed more testing). Are you 
running into this problem?

-Alan.