RFC: Too many race conditions.

Tue May 22 05:56:00 GMT 2007

David Daney wrote:
> The semantics of files and pipes change if you don't close them when
> the application asks for them to be closed.

[...]
> We cannot cause a close operation to block where it currently does not.

I think these two requirements are not compatible.
> When the close call returns to the caller, we cannot still have the
> resource open.

I think it's actually fairly reasonable that close() doesn't immediately close a resource if it's being used on another thread (however, I would expect any blocking operation to be aborted, so some kind of signal needs to be sent to the other thread).
> Also counting references requires obtaining some type of mutual
> exclusion lock twice for each I/O operation. This would add overhead
> to the current implementation.

That shouldn't be that big compared to a user/kernel/user transition.
Anyway, IMNSHO all this talk about compatibility, performance and whatnot is irrelevant, security trumps that every time. Having a race that allows access to otherwise unaccessible file descriptors is unacceptable (no matter how small the window) if you want to support running untrusted code.
Regards,
Jeroen