Web lists-archives.com

Re: I'm done with O_CLOEXEC




On lör, 2015-03-21 at 20:57 -0400, Ryan Lortie wrote:
> 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.

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.

In general, setting O_CLOEXEC is a nice thing to do, but doing so does
not change the fundamental fact that you can't rely on it being set.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@xxxxxxxxxx            alexander.larsson@xxxxxxxxx 
He's an ungodly misogynist librarian trapped in a world he never made. 
She's a plucky hip-hop doctor from out of town. They fight crime! 

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list