Re: I'm done with O_CLOEXEC

[Ryan Lortie <desrt desrt ca>]

hi,

On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote:
> I would keep using O_CLOEXEC as it's as close as we can get to the
> behavior that should have been the default: don't implicitly inherit
> file descriptors on exec.
>
> Maybe there are applications out there that rely on correct file
> descriptor flags and directly call fork/exec. You could try to convince
> them to switch to GSubprocess (or work around the issue in their own
> fork/exec code). However, as I think we all agree that O_CLOEXEC is the
> best default behavior, I don't see why we should break these
> applications.

This is probably the best counter-argument so far: since we all agree
that the inherit-by-default behaviour is silly, we should try as much as
possible to mitigate it.

I agree with that point, but the main thrust of the argument that I was
trying to make originally (and somewhat detracted from with my ranting)
is:

 - there is often a high price to pay for "doing the right thing"; and

 - it's not actually necessary

Sure, it's conceivable (and even likely) that there is code that isn't
up to snuff, but that's sort of the point of this thread.  I want to
shift responsibility for "getting this right" from the innumerably many
places that we create fds to the very few places that we launch
subprocesses.

And by the way: the "high price" that we pay is not just in cases where
we need to implement one codepath for Linux and a fallback for other
platforms inside of GLib.  If you fully buy into the O_CLOEXEC mantra,
then it means that every single person who casually calls open() (even
in application code) needs to take care to get it right, for fear that
some naive library is doing fork()/exec() in another thread.

Cheers