Re: I'm done with O_CLOEXEC


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

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)

 - 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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]