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: > > 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.
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 al...@redhat.com alexander.lars...@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! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list