Messages in this thread |  | | | Date | Mon, 29 Mar 2004 10:59:08 -0800 | | From | Ulrich Drepper <> | | Subject | Re: For the almost 4-year anniversary: O_CLOEXEC again |
| |
Jamie Lokier wrote:
> 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.
It's not OK since library functions can install signal handlers and they need not be aware of everything the application does.
Any globally visible change in the behavior can have negative effects.
Yes, there are other calls but open() is far more critical since it is now promoted not only to an interface to actually do work. We are supported to read kernel and system informatino from /proc which requires open().
And no, oen() is not the only signal-safe function. If you don't have the POSIX specs handy, look at a recent signal(2) man page which lists the signal-safe functions. accept(), socket() are on the list among others.
-- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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/
|  |