[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature request: process creation
From: |
Derek Upham |
Subject: |
Re: feature request: process creation |
Date: |
Mon, 26 Jun 2017 19:46:45 -0700 |
User-agent: |
mu4e 0.9.17; emacs 25.1.1 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: feature request: process creation,
Derek Upham <=