Messages in this thread |  | | | Date | Mon, 29 Mar 2004 14:18:19 +0100 | | From | Jamie Lokier <> | | Subject | Re: For the almost 4-year anniversary: O_CLOEXEC again |
| |
Ulrich Drepper wrote: > It cannot be done through a per-thread switch which decides whether > newly allocated descriptors are CLOEXEC until further notice since > open() is a signal-safe interface. The signal handler code might > not be aware of this mode and create descriptors which are not > inherited.
Since O_CLOEXEC is non-portable, why not implement the per-thread switch?
Signal handlers that call open() will have to be aware of it, but that's ok: an application will only set the switch if it knows what that implies.
For POSIX compatibility the switch should be off initially, and only turned on at the application's request.
Portable code which assumes POSIX interfaces has to have another way to work around the close-on-exec problem anyway.
Overall I like the O_CLOEXEC flag. It really should have always been an O_* flag, and F_SETFL should be able to change it.
The only problem is there are so many other ways to get file descriptors which it doesn't help with. Most especially sockets, which are heavily used in the kinds of programs which use threads and and forking.
Btw, is open() the only signal-safe interface where this matters? Perhaps a per-thread flag could be used for all the _other_ file descriptor generating interfaces, but not for open() where only O_CLOEXEC would work?
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |