On Fri, 2015-03-20 at 16:43 -0400, Ryan Lortie wrote:
What led me to this was the dup3() system call. This is a variant of
dup2() that was added (as part of the efforts mentioned above) to avoid
the O_CLOEXEC race:
int dup3(int oldfd, int newfd, int flags);
unfortunately:
dup3(0,
On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote:
It seems that this is a (slightly) recent addition. It's documented:
F_DUPFD_CLOEXEC (int; since Linux 2.6.24)
so I'm sure we'll probably still need to write an ifdef with a
fallback...
If you're referring to older Linux
On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie de...@desrt.ca wrote:
The first one, which we have been pursuing during the past several
years, is to try to mark every file descriptor that we create as
O_CLOEXEC. This is particularly fun in multi-threaded programs because
it means that we have
On Sat, Mar 21, 2015 at 1:10 AM, Ryan Lortie de...@desrt.ca wrote:
On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote:
So, you found that dup3 doesn't do what you want, and now you want to
throw out the baby with the bathwater and just say I don't care
anymore if we leak fds ?
dup3() was
On Sat, Mar 21, 2015 at 9:39 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
Before we can have constructive arguments, we first need to understand
what you are actually proposing. Most of your mail was an extended
whine about inadequacies of posix in general, and fd inheritance in
On Sat, 21 Mar 2015 06:59:41 +0100
Jürg Billeter j...@bitron.ch wrote:
On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote:
It seems that this is a (slightly) recent addition. It's
documented:
F_DUPFD_CLOEXEC (int; since Linux 2.6.24)
so I'm sure we'll probably still need
On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote:
hi,
On Sat, Mar 21, 2015, at 01:27, Jürg Billeter wrote:
Doesn't the following standard POSIX functionality provide what you
want?
fcntl(fd, F_DUPFD_CLOEXEC, 0)
Yes. It does. Thank you very much.
It seems that this is a
On Sat, Mar 21, 2015 at 12:31 PM Chris Vine ch...@cvine.freeserve.co.uk
wrote:
Further, there are cases where porting to GSubprocess does not actually
do the job easily because (as I understand it) GSubprocessFlags
can be set to either close all descriptors on exec other than those for
On Sat, 21 Mar 2015 13:47:04 +
Florian Müllner fmuell...@gnome.org wrote:
On Sat, Mar 21, 2015 at 12:31 PM Chris Vine
ch...@cvine.freeserve.co.uk wrote:
Further, there are cases where porting to GSubprocess does not
actually do the job easily because (as I understand it)
On Sat, Mar 21, 2015, at 12:04, Matthias Clasen wrote:
'Not part of POSIX' has never stopped us from using something in glib:
atomics, futexes, inotify, pipe2, libelf, to name just a few...
...and in each of these cases, we pay the price with some sort of
abstraction layer, #ifdef, fallback
On Sat, Mar 21, 2015, at 12:09, Matthias Clasen wrote:
Are you actually suggesting that we rip out all code that is currently
doing the right thing, cloexec-wise ?
from my original email:
I'm not going to go and retroactively tear things out where they are
already working, unless it would
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
12 matches
Mail list logo
