Fun with file descriptors [LWN.net]

Fun with file descriptors

Posted Jun 7, 2007 5:48 UTC (Thu) by daney (subscriber, #24551)
Parent article: Fun with file descriptors

The O_CLOEXEC for open(2) is a good start, but it is not sufficient. We need coverage for accept(2) also. I am not sure if there are other ways of creating file descriptors, but unless you plug them all, you have to assume that the race condition will occur and take precautions. If you have to take these precautions, then fixing only a portion of the causes (fixing open(2)) is not all that useful.

Another nasty race condition that I have considered is:

Thread 1                Thread 2               Thread 3
---------------------------------------------------------------
load fd from memory     load fd from memory
                        close fd
                                               obtain same fd from open
use fd on wrong file

If Thread 3 did not reuse the fd there would not be a problem.

I am glad that people are starting to address these issues.

(Log in to post comments)

Fun with file descriptors

Posted Jun 7, 2007 11:52 UTC (Thu) by HenrikH (guest, #31152) [Link]

But this should be controlled by the application using mutexes to lock the access to the fd and you probably have some struct holding the fd that will also be freed upon the "close fd" so that thread #1 no longer can access the same fd after it is closed by thread #2.

That said however, it would be nice to avoid the reuse of the fd as it is now.

Fun with file descriptors

Posted Jun 7, 2007 16:41 UTC (Thu) by daney (subscriber, #24551) [Link]

The problem being is that if you use a mutex to protect a blocking read, you can not interrupt it by closing the file descriptor as the thread calling close would block on the mutex.

There are ways to work around the current state of things, but the problem is that they are often complex and easy to get wrong.

Fun with file descriptors

Posted Jun 12, 2007 15:23 UTC (Tue) by shane (subscriber, #3335) [Link]

The problem being is that if you use a mutex to protect a blocking read, you can not interrupt it by closing the file descriptor as the thread calling close would block on the mutex.

Yes, this is a tricky problem.

You can create a file descriptor that you can "wake" the blocking thread and then use select() or poll(). You can use a pipe for this (of course you have to be careful to handle closing the pipe then).

You can also use a condition variable for the reader, and a separate thread checking for input that signals the reader. A 3rd thread should be able to close the file descriptor, which should then return EBADF from it's select() or poll(). (I think...)

Sharing file descriptors between threads is indeed a pain in the ass though. Correct threaded programming is fairly difficult, it makes one wonder if maybe good old event-driven programming wasn't really the answer all along!

Fun with file descriptors

Posted Jul 1, 2008 21:21 UTC (Tue) by dankamongmen (subscriber, #35141) [Link]

I'm being brutally bent over by the lack of an accept(2) solution right now (I'm docing the
changes as they come along, btw; see:
http://dank.qemfd.net/dankwiki/index.php/Linux_APIs#File_...). It seems setsockopt(2)
could be easily enough overloaded for this purpose...argh!