[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introduce posix_spawn

From: Eric Blake
Subject: Re: Introduce posix_spawn
Date: Sat, 8 Sep 2018 15:50:29 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 09/08/2018 02:24 AM, Bernhard Voelker wrote:
On 09/08/18 00:15, Eric Blake wrote:
Adding posix_spawn_file_actions_addchdir() is what avoids the need to
lock in the parent, because now you do:

A thought WRT the naming: while ..._addopen() can be called for more file
descriptors, there's only one working directory for the spawned process.
Therefore I suggest to simply call it posix_spawn_file_actions_chdir(),
i.e., without the "add" in its name.
To "remove" this from the posix_spawn_file_actions again (before calling
posix_spawn, of course), one could also simply use


I'm not a fan of it. Remember, we already have posix_spawn_file_actions_addclose().

The _add name is representing the fact that you are adding to the growing list of file_actions to be applied later.

You can't undo a chdir; but you CAN do multiple chdir to affect intermediate state, where only the last chdir determines where the current working directory of the child will be.

And the fact that Solaris already has posix_spawn_file_actions_addchdir_np() is pretty strong precedent for keeping the name _addchdir, rather than picking a different name (we're dropping the _np suffix as part of standardizing things, since _np means non-portable but a standardized version is portable - but nothing else really needs to change from what has already been implemented in other platforms).

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]