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 <address@hidden> 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
address@hidden