feature request: process creation

feature request: process creation

[j kalbhenn]

currently i am struggling with fork/exec/dup/etc and am missing a more generic way to create processes in guile. i wish i could avoid having to require building a shared library to use the scheme code that i am writing.
my use case is that i would like to "chain" the i/o of several child processes with more control over the standard streams, to use named pipes inbetween for example. but i also think such a feature would be nice to have in general.

guile has (ice-9 popen), which creates a child process with pipes to/from it but does not offer many parameters.
guile-lib has (os process), but apart from also not exactly being the generic procedure i am looking for, i am not sure if it is up to date and robust, the naming of the bindings might also not be ideal.

what i would like to see is a procedure that creates a new child process with a signature similar to this:

process-create :: executable-path #:optional (arguments (list)) input-port output-port error-port #:key (env (environ)) (keep-descriptors (list))
               -> process-id

input/output/error-port: can be guile ports and maybe file descriptors. they can also be false in which case the corresponding standard stream is set to /dev/null
keep-descriptors: a list of file descriptors that stay available in the new process

eventually
* the working directory
* other process attributes

behaviour
* it closes all file-descriptors for the new process except for the ones passed as standard streams and those listed by the user. this way there is no need to give the user a way to manually close ports in the forked process or set O_CLOEXEC on every port
* it uses execve to be async-signal-safe (that is also part of the reason why it should be implemented in C)
* the first argument to execve is always the basename of the path to the executable, which is a common convention (good idea?)
* if the path to the executable does not start with a slash then it is searched in PATH (security implications? maybe optional)

i might be able to implement it.
real world examples of such a procedure can be found in node.js' child_process and golangs startprocess.

by the way,
i see in guiles posix.c L1317 that popen uses execvp  - afaik that is not async-signal-safe (http://man7.org/linux/man-pages/man7/signal-safety.7.html).
popen also tries to close all file descriptors and that process could be improved perhaps. just something i have read about (https://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor
): it gets the maximum number of file descriptors soft limit (which might have been lowered at some point) using the linux specific getrlimit and 1024 if that is not available (can't there be file descriptors above 1024?).

Re: feature request: process creation

[Derek Upham]

I’m working on an implementation of SCSH’s process forms (https://scsh.net/docu/html/man-Z-H-3.html#node_chap_2), which would do what you want.  There’s a bug in Guile’s thread-join implementation that causes occasional race conditions.  No one has had time to take a look at yet; I may have an opportunity soon.

Derek

j kalbhenn <jkal@posteo.eu> writes:

> currently i am struggling with fork/exec/dup/etc and am missing a more generic way to create processes in guile. i wish i could avoid having to require building a shared library to use the scheme code that i am writing.
> my use case is that i would like to "chain" the i/o of several child processes with more control over the standard streams, to use named pipes inbetween for example. but i also think such a feature would be nice to have in general.
>
> guile has (ice-9 popen), which creates a child process with pipes to/from it but does not offer many parameters.
> guile-lib has (os process), but apart from also not exactly being the generic procedure i am looking for, i am not sure if it is up to date and robust, the naming of the bindings might also not be ideal.
>
> what i would like to see is a procedure that creates a new child process with a signature similar to this:
>
> process-create :: executable-path #:optional (arguments (list)) input-port output-port error-port #:key (env (environ)) (keep-descriptors (list))
>                -> process-id
>
> input/output/error-port: can be guile ports and maybe file descriptors. they can also be false in which case the corresponding standard stream is set to /dev/null
> keep-descriptors: a list of file descriptors that stay available in the new process
>
> eventually
> * the working directory
> * other process attributes
>
> behaviour
> * it closes all file-descriptors for the new process except for the ones passed as standard streams and those listed by the user. this way there is no need to give the user a way to manually close ports in the forked process or set O_CLOEXEC on every port
> * it uses execve to be async-signal-safe (that is also part of the reason why it should be implemented in C)
> * the first argument to execve is always the basename of the path to the executable, which is a common convention (good idea?)
> * if the path to the executable does not start with a slash then it is searched in PATH (security implications? maybe optional)
>
> i might be able to implement it.
> real world examples of such a procedure can be found in node.js' child_process and golangs startprocess.
>
> by the way,
> i see in guiles posix.c L1317 that popen uses execvp  - afaik that is not async-signal-safe (http://man7.org/linux/man-pages/man7/signal-safety.7.html).
> popen also tries to close all file descriptors and that process could be improved perhaps. just something i have read about (https://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor
> ): it gets the maximum number of file descriptors soft limit (which might have been lowered at some point) using the linux specific getrlimit and 1024 if that is not available (can't there be file descriptors above 1024?).


-- 
Derek Upham
sand@blarg.net