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 <j...@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 s...@blarg.net
