Fun with file descriptors
Posted Jun 8, 2007 7:16 UTC (Fri) by quotemstr
In reply to: Fun with file descriptors
Parent article: Fun with file descriptors
What about a thread-specific default set of FD flags?
Using something like this, we wouldn't need to modify any existing APIs.
/* Internal glibc function */
A: old_fd_flags = kernel_default_fd_flags(FD_CLOEXEC | FD_RANDFD);
B: event_fd = super_duper_event_polling_mechanism_fd();
Since the state is thread-specific, we don't need to worry about cross-thread synchronization. It wouldn't be inherited across exec, fork or clone, since it's intended for purely local options. I can't think of a situation where one would want to create a new thread and atomically give it a default set of FD flags.
It's race-free as well. If a fork happens between A and B, nothing unusual happens; the child process doesn't inherit the thread setting flags. If a fork happens after B, event_fd is closed when the child exec()s.
It's adheres to POSIX as long as the application doesn't touch kernel_default_fd_flags itself, and as long as any libraries restore flags after they're done with them.
Why not add an FD_CLOFORK owhile we're at it? That's a lot closer to what you'd want for a piece of code that allocated an internal file descriptor. Granted, multithreaded programs shouldn't fork except to then exec.
to post comments)