This is the mail archive of the
mailing list for the glibc project.
Re: [RFC/PATCH glibc 0/2] setting working dir in posix_spawn()
- From: Eric Blake <eblake at redhat dot com>
- To: Jonathan Nieder <jrnieder at gmail dot com>
- Cc: Austin Group <austin-group-l at opengroup dot org>, libc-alpha at sourceware dot org
- Date: Fri, 7 Sep 2018 17:54:53 -0500
- Subject: Re: [RFC/PATCH glibc 0/2] setting working dir in posix_spawn()
- References: <alpine.LFD.email@example.com> <20100825013625.GC10423@burratino> <4C74BFA7.firstname.lastname@example.org> <4C752739.email@example.com> <20100826061815.GH9708@burratino> <4C767682.firstname.lastname@example.org> <20100827063546.GB32454@burratino>
[reviving a REALLY old thread]
On 08/27/2010 01:35 AM, Jonathan Nieder wrote:
(pruned cc's, +cc:libc-alpha)
Eric Blake wrote:
On 08/26/2010 12:18 AM, Jonathan Nieder wrote:
Do you think there would be any interest in a posix_spawn() variant
that takes a dir parameter? I am imagining something like this:
Of your variants, I would most prefer:
*file_actions, int dirfd);
Today, I just submitted http://austingroupbugs.net/view.php?id=1208,
then in searching my mail archives, I found this related thread that
never had a response at the time, so I'm now offering a reply. Compared
to my thoughts 8 years ago, my new writeup proposed
*restrict file_actions, const char *restrict name);
*file_actions, int dirfd);
which is slightly different from your RFC based on my older thoughts.
But in re-reading your email, I see that we could indeed get by with
JUST the fchdir() signature, since chdir("foo") can generally be
decomposed into fchdir(open("foo", O_RDONLY|O_DIRECTORY)).
Okay, here's a proof of concept (for the easy case --- a fork()-
based implementation for Linux). Patches apply to 8b2b771^.
For that matter, it may also be worth adding
posix_spawn_file_actions_addopenat, which mirrors the recent
addition of openat() semantics.
Sounds like a good idea. I did not try it because I did not want to
think about whether it would cause the __spawn_action struct to grow
(and if so, what ramifications that would have, if any).
Also, I've realized that we do NOT need
posix_spawn_file_actions_addopenat(). The main benefit of openat() is
that you can redirect relative file names according to an fd of your
choice, without affecting global state. But during posix_spawn(), there
are no other threads competing for global state (if you are doing a
library implementation where the chdir() is done between fork() and
openat(mydir, "file", mode);
can be decomposed to:
posix_spawn_file_actions_addopen(&act, 5, ".", O_RDONLY|O_DIRECTORY, 0);
posix_spawn_file_actions_addopen(&act, 4, "file", mode, 0);
We don't need to add posix_spawn_file_actions_addFOO for every possible
FOO that typically gets called between fork/exec, as long as we can
string together enough bare components to get the feature parity within
the single-threaded context of posix_spawn() for what is otherwise
expensive if done in the parent as a wrapper around posix_spawn(), even
if it adds more verbosity into the posix_spawn_* calls require to get
the same desired effects.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org