Ghosts of Unix past, part 2: Conflated designs

Posted Nov 8, 2010 19:54 UTC (Mon) by dd9jn (✭ supporter ✭, #4459)
In reply to: Ghosts of Unix past, part 2: Conflated designs by Yorick
Parent article: Ghosts of Unix past, part 2: Conflated designs

> perhaps should take a list of descriptors to preserve

An easier and compatible fix would be a system call to close all file descriptors except those given to that call. The workaround everyone uses today, figuring out the maximum number file descriptors possible and call close(2) for each of them, is quite expensive in terms of system calls (~1000 calls in standard situations).

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 8, 2010 21:13 UTC (Mon) by Yorick (guest, #19241) [Link] (5 responses)

Reading /proc/self/fd/ and closing only those found there is a bit better, but not quite as portable and still a lot slower than something like BSD closefrom(), which surely would be handy.
But it would still be inferior to having CLOEXEC by default (or passing a list of descriptors to preserve to exec). It is way too easy to leak descriptors by accident or because of careless code in a library.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 1:10 UTC (Thu) by jonabbey (guest, #2736) [Link] (3 responses)

Reading from /proc/self/fd and closing descriptors based on that is still subject to race conditions in threaded programs.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 2:38 UTC (Thu) by foom (subscriber, #14868) [Link]

Nope, it's not, because you do the closing of fds after forking (but before exec). You are guaranteed that there will be no other threads running at that point.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 3:30 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

After fork(), a program has one thread.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 17, 2010 0:23 UTC (Wed) by mhelsley (guest, #11324) [Link]

And if your process links with libraries that internally use fds then you could easily trample the "internal" workings of those libraries by closing the fds. So a naive process can't assume it knows how to handle each fd in /proc/self/fd* without blurring the lines between library and application.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 11:28 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Thanks for the pointer to closefrom - not exactly what I want but helpful. Time for a new configure test. And, yes, /proc/foo is not portable enough.