Message-ID: <406871FC.1070700@redhat.com>
Date: Mon, 29 Mar 2004 10:59:08 -0800
From: Ulrich Drepper <drepper@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040328
MIME-Version: 1.0
To: Jamie Lokier <jamie@shareable.org>
CC: "linux-kern >> Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: For the almost 4-year anniversary: O_CLOEXEC again
References: <40677D1B.9060801@redhat.com> <20040329131819.GF4984@mail.shareable.org>
In-Reply-To: <20040329131819.GF4984@mail.shareable.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1227
Lines: 30

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/