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:
>
>
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 v
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 (slightly) recent addition. It's documented:
F_DUP
hi,
On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote:
> Right now, we use raw fork/exec in mutter where we need to do some tricky
> management and explicitly leak an FD into the correct place [0]. Does
> this
> mean that from now on, glib might leak an FD and we need to be prepared
> to
> h
On Fri, Mar 20, 2015, at 20:29, Christian Hergert wrote:
> What I would welcome, is a function that says "glib, close all FDs you
> know about or that you created". If all the libraries did that, at least
> it would be possible for applications to maybe, sorta, do the right
> thing. (That would
Sorry, I'm not overly familiar with this sort of stuff.
Right now, we use raw fork/exec in mutter where we need to do some tricky
management and explicitly leak an FD into the correct place [0]. Does this
mean that from now on, glib might leak an FD and we need to be prepared to
handle that? Refac
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 a bit of a "straw that broke the camel's back" case. I could
po
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" ?
On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie wrote:
> karaj,
>
> For those unfamiliar with the issue: when a process is created on UNIX
On Fri, Mar 20, 2015 at 7:29 PM, Christian Hergert
wrote:
>
> This makes me happy. I don't think I've actually seen any of this stuff
> handled right. Not to mention that close() itself is basically broken in
> multi-threaded scenarios on Linux (Linus says to basically "just not worry
> about it
On 03/20/2015 01:43 PM, Ryan Lortie wrote:
karaj,
For those unfamiliar with the issue: when a process is created on UNIX
via naive fork() and exec(), the default is that the process will
inherit all of the file descriptors of the parent. This makes a lot of
sense for stdin, stdout and stderr, b
karaj,
For those unfamiliar with the issue: when a process is created on UNIX
via naive fork() and exec(), the default is that the process will
inherit all of the file descriptors of the parent. This makes a lot of
sense for stdin, stdout and stderr, but almost nothing else.
This has been the ca
11 matches
Mail list logo
