From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: j kalbhenn Newsgroups: gmane.lisp.guile.devel Subject: feature request: process creation Date: Sun, 28 May 2017 09:51:18 +0000 Message-ID: <20170528095117.GA4149@sph-desktop.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1495978409 19603 195.159.176.226 (28 May 2017 13:33:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 May 2017 13:33:29 +0000 (UTC) User-Agent: Mutt/1.8.2 (2017-04-18) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 28 15:33:24 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEyJw-0004yl-FL for guile-devel@m.gmane.org; Sun, 28 May 2017 15:33:24 +0200 Original-Received: from localhost ([::1]:43999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEyK1-000385-PC for guile-devel@m.gmane.org; Sun, 28 May 2017 09:33:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEurE-0007Ek-44 for guile-devel@gnu.org; Sun, 28 May 2017 05:51:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEurB-0002ev-1O for guile-devel@gnu.org; Sun, 28 May 2017 05:51:32 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:44719) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dEurA-0002dM-Qw for guile-devel@gnu.org; Sun, 28 May 2017 05:51:28 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 36F6B20935 for ; Sun, 28 May 2017 11:51:20 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3wbFWC28ncz10BH for ; Sun, 28 May 2017 11:51:19 +0200 (CEST) Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-Mailman-Approved-At: Sun, 28 May 2017 09:33:26 -0400 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19170 Archived-At: 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?).