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?).