Re: I'm done with O_CLOEXEC

On tis, 2015-03-31 at 09:48 +0200, Alexander Larsson wrote:
On lör, 2015-03-21 at 20:57 -0400, Ryan Lortie wrote:

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.

Overall I don't quite see what the argument is, other than the above
which I agree with.

Its a fact of life that O_CLOEXEC (and the threadsafe setting of it) is
not universally available on the systems we support glib on. This means
we *have* to close all open fds in e.g. g_spawn(), and no code can
safely rely on it having been used on all open fds.

Actually, what *really* would help here in terms of kernel support would
be a syscall that closed a range of fds. This could be very efficient in
the kernel, avoiding the issues with the close-after-fork solution, but
very easily put into use.

 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a fiendish vegetarian master criminal with no name. She's an 
artistic mutant hooker with an MBA from Harvard. They fight crime! 

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