This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/PATCH glibc 0/2] setting working dir in posix_spawn()


[reviving a REALLY old thread]
https://sourceware.org/ml/libc-alpha/2010-08/msg00107.html

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:

  int posix_spawn_file_actions_addchdir(posix_spawn_file_actions_t
	*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

int posix_spawn_file_actions_addchdir(posix_spawn_file_actions_t *restrict file_actions, const char *restrict name); int posix_spawn_file_actions_addfchdir(posix_spawn_file_actions_t *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 exec()), so:

openat(mydir, "file", mode);

can be decomposed to:

posix_spawn_file_actions_addopen(&act, 5, ".", O_RDONLY|O_DIRECTORY, 0);
posix_spawn_file_actions_addfchdir(&act, mydir);
posix_spawn_file_actions_addopen(&act, 4, "file", mode, 0);
posix_spawn_file_actions_addfchdir(&act, 5);
posix_spawn_file_actions_addclose(&act, 5);

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]