posix: New function posix_spawn_file_actions_addchdir_np [BZ #17405]
Commit Message
On 10/30/18 1:50 AM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> On 10/26/18 10:07 AM, Florian Weimer wrote:
>>> I'm not adding documentation in this patch because none exists for the
>>> posix_spawn functionality.
>>
>> We can do better though, I'm happy even if we just add the prototypes
>> into the manual to give others a place to hang more text in the future.
>> The safety notes would be helpful too, is it MT-safe, AS-safe etc.
>>
>> Would you please take a stab at adding something minimal?
>
> I don't want to make *any* changes to the manual at this point, sorry.
Thanks. I appreciate the direct answer. I will try to take a stab at
some initial documentation for posix_spawn and posix_spawnp so that
we have somewhere to hang future changes.
For example:
~~~
And then define the file actions, and spawn attributes.
Then add the funcitions themselves to get and set various properties.
* posix_spawn_file_actions_addclose
* posix_spawn_file_actions_adddup2
* posix_spawn_file_actions_addopen
* posix_spawn_file_actions_destroy
* posix_spawn_file_actions_init
* posix_spawnattr_destroy
* posix_spawnattr_getflags
* posix_spawnattr_getpgroup
* posix_spawnattr_getschedparam
* posix_spawnattr_getschedpolicy
* posix_spawnattr_getsigdefault
* posix_spawnattr_getsigmask
* posix_spawnattr_init
* posix_spawnattr_setflags
* posix_spawnattr_setpgroup
* posix_spawnattr_setschedparam
* posix_spawnattr_setschedpolicy
* posix_spawnattr_setsigdefault
* posix_spawnattr_setsigmask
Is anything else required?
Comments
On Wed, Oct 31, 2018 at 10:03:26PM -0400, Carlos O'Donell wrote:
> On 10/30/18 1:50 AM, Florian Weimer wrote:
> > * Carlos O'Donell:
> >
> >> On 10/26/18 10:07 AM, Florian Weimer wrote:
> >>> I'm not adding documentation in this patch because none exists for the
> >>> posix_spawn functionality.
> >>
> >> We can do better though, I'm happy even if we just add the prototypes
> >> into the manual to give others a place to hang more text in the future.
> >> The safety notes would be helpful too, is it MT-safe, AS-safe etc.
> >>
> >> Would you please take a stab at adding something minimal?
> >
> > I don't want to make *any* changes to the manual at this point, sorry.
>
> Thanks. I appreciate the direct answer. I will try to take a stab at
> some initial documentation for posix_spawn and posix_spawnp so that
> we have somewhere to hang future changes.
>
> For example:
>
> diff --git a/manual/process.texi b/manual/process.texi
> index b82b91f9f1..efa0bb8b14 100644
> --- a/manual/process.texi
> +++ b/manual/process.texi
> @@ -34,6 +34,7 @@ primitive functions to do each step individually instead.
> * Process Identification:: How to get the process ID of a process.
> * Creating a Process:: How to fork a child process.
> * Executing a File:: How to make a process execute another program.
> +* POSIX Spawn:: Combining fork and exec into spawn.
Maybe it can't be helped, but I feel like this misrepresents and
de-motivates posix_spawn. Perhaps instead something like "Execute
another program as a child process without the need to fork".
Rich
On 10/31/18 11:03 PM, Rich Felker wrote:
> On Wed, Oct 31, 2018 at 10:03:26PM -0400, Carlos O'Donell wrote:
>> On 10/30/18 1:50 AM, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>> On 10/26/18 10:07 AM, Florian Weimer wrote:
>>>>> I'm not adding documentation in this patch because none exists for the
>>>>> posix_spawn functionality.
>>>>
>>>> We can do better though, I'm happy even if we just add the prototypes
>>>> into the manual to give others a place to hang more text in the future.
>>>> The safety notes would be helpful too, is it MT-safe, AS-safe etc.
>>>>
>>>> Would you please take a stab at adding something minimal?
>>>
>>> I don't want to make *any* changes to the manual at this point, sorry.
>>
>> Thanks. I appreciate the direct answer. I will try to take a stab at
>> some initial documentation for posix_spawn and posix_spawnp so that
>> we have somewhere to hang future changes.
>>
>> For example:
>>
>> diff --git a/manual/process.texi b/manual/process.texi
>> index b82b91f9f1..efa0bb8b14 100644
>> --- a/manual/process.texi
>> +++ b/manual/process.texi
>> @@ -34,6 +34,7 @@ primitive functions to do each step individually instead.
>> * Process Identification:: How to get the process ID of a process.
>> * Creating a Process:: How to fork a child process.
>> * Executing a File:: How to make a process execute another program.
>> +* POSIX Spawn:: Combining fork and exec into spawn.
>
> Maybe it can't be helped, but I feel like this misrepresents and
> de-motivates posix_spawn. Perhaps instead something like "Execute
> another program as a child process without the need to fork".
How about something shorter like:
"Execute a child process without fork"
Does it matter that the underlying implementation may use for?
I'd say, no it doesn't, what we're explaining is that you can
use posix_spawn to start a child process without the need for
you to also call fork or exec. Right?
* Carlos O'Donell:
> How about something shorter like:
>
> "Execute a child process without fork"
I think the reference point should not be fork, but popen and system.
The theme should be one of these:
“Start a program in a subprocess”
“Launch a separate program”
I would say the key differences are:
* More control over the descriptors and other process properties.
* The shell is not used.
* Execution can be interleaved with the existing process (unlike system).
The existing popen documentation probably needs updates as well.
On Thu, Nov 01, 2018 at 12:06:39PM +0100, Florian Weimer wrote:
> * Carlos O'Donell:
>
> > How about something shorter like:
> >
> > "Execute a child process without fork"
Omitting the word program fails to get across the main point I think
-- that it's a new program (executable file) being run.
> I think the reference point should not be fork, but popen and system.
> The theme should be one of these:
>
> “Start a program in a subprocess”
> “Launch a separate program”
Yes. I agree it's more closely associated with these, but I hope the
placement will draw attention to it as a better alternative to
fork+exec as well. In some sense exec belongs here as "replace the
current process..."
> I would say the key differences are:
>
> * More control over the descriptors and other process properties.
> * The shell is not used.
> * Execution can be interleaved with the existing process (unlike system).
Also, system() alters global signal disposition and is not suitable
for use in a multithreaded program.
Rich
@@ -34,6 +34,7 @@ primitive functions to do each step individually instead.
* Process Identification:: How to get the process ID of a process.
* Creating a Process:: How to fork a child process.
* Executing a File:: How to make a process execute another program.
+* POSIX Spawn:: Combining fork and exec into spawn.
* Process Completion:: How to tell when a child process has completed.
* Process Completion Status:: How to interpret the status value
returned from a child process.
@@ -497,6 +498,65 @@ they do not have @code{FD_CLOEXEC} set). The new process image can
reconnect these to new streams using @code{fdopen} (@pxref{Descriptors
and Streams}).
+@node POSIX Spawn
+@section POSIX Spawn
+@cindex spawning a new process
+@cindex @code{posix_spawn} related functions
+
+The POSIX standard defines a set of functions which incorporate the
+common set of steps generally taken by @code{fork} and @code{exec}
+functions and puts them together into a portable set of APIs. These
+APIs allow the caller to @code{fork} a new process under the control
+of various options, carry out some pre-@code{exec} steps, and finally
+@code{exec} (again under the control of various options). The APIs
+
+@deftypefun int posix_spawn (pit_d *pid, const char *path,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argvp[], char *const envp[])
+
+Create a new child process by executing the @code{path} file. The
+execution of @code{path} follows three stages, first the @code{fork} stage,
+then the pre-@code{exec} stage, and lastly the @code{exec} stage. The actions
+taken at each step are described by the @code{posix_spawn_file_actions_t}
+and @code{posix_spawnattr_t} structures, with @code{argvp} and @code{envp}
+providing argument and environment pointers for the new child process.
+
+The @code{pid} pointer will contain the new PID of the child if
+execution is successful.
+@end deftypefun
+
+@deftypefun int posix_spawnp (pit_d *pid, const char *file,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argvp[], char *const envp[])
+
+Create a new child process by executing the @code{file} if it contains a
+slahs character, or the @code{PATH} environment variable will be
+searched for file. The execution of @code{path} follows three stages,
+first the @code{fork} stage, then the pre-@code{exec} stage, and lastly
+the @code{exec} stage. The actions taken at each step are described by
+the @code{posix_spawn_file_actions_t} and @code{posix_spawnattr_t}
+structures, with @code{argvp} and @code{envp} providing argument and
+environment pointers for the new child process.
+
+The @code{pid} pointer will contain the new PID of the child if
+execution is successful.
+@end deftypefun
+
+@section POSIX Spawn File Actions
+
+@section POSIX Spawn Attributes
+
+
+
+
+
+
+
+
+
+
@node Process Completion
@section Process Completion
@cindex process completion