From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Using file descriptors in Emacs Date: Sun, 11 Sep 2016 12:57:25 -0400 Message-ID: <87zinez85m.fsf@earth.catern.com> References: <1465262706-5229-1-git-send-email-sbaugh@catern.com> <87twfevqu7.fsf@earth.catern.com> <87pood5fee.fsf@earth.catern.com> <834m5p83yy.fsf@gnu.org> <877fal56zh.fsf@earth.catern.com> <83d1kcaowk.fsf@gnu.org> <8737l86glg.fsf@earth.catern.com> <837fakan8b.fsf@gnu.org> <87r38s4xmv.fsf@earth.catern.com> <83oa3w8byt.fsf@gnu.org> <87twdn25ib.fsf@earth.catern.com> <83d1kabgms.fsf@gnu.org> <87d1ka1l62.fsf@earth.catern.com> <8337l6bdcl.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473613111 10949 195.159.176.226 (11 Sep 2016 16:58:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Sep 2016 16:58:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 11 18:58:26 2016 Return-path: Envelope-to: ged-emacs-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 1bj85G-0001rS-Em for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 18:58:22 +0200 Original-Received: from localhost ([::1]:38408 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj85E-000347-Jq for ged-emacs-devel@m.gmane.org; Sun, 11 Sep 2016 12:58:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj84h-00033n-RI for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:57:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj84d-0002rs-FR for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:57:47 -0400 Original-Received: from [195.159.176.226] (port=49014 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj84d-0002r5-8h for emacs-devel@gnu.org; Sun, 11 Sep 2016 12:57:43 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bj84U-0004zt-67 for emacs-devel@gnu.org; Sun, 11 Sep 2016 18:57:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 48 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:pl9LgOGxR7lvDqG6tSvkTwP9hjU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207366 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sun, 11 Sep 2016 12:00:21 -0400 >> >> I suppose one could add the capability to pass in a process object as >> the source of input for a new process object. This could be implemented >> by forcing the passed-in process object to a state where it does not >> have (and cannot have) a process-filter function. Then the file >> descriptor used for input to the passed-in process object could be >> manipulated appropriately to make it the stdin of the new process >> object. The new process object in turn will be in a special state where >> it cannot accept input from Emacs. >> >> Likewise for the capability to pass in a process object as the >> destination for a program's output, instead of a process-filter, and the >> capability to redirect arbitrary file descriptor numbers to point at >> process objects (or other file descriptors). >> >> Then also it is necessary to handle redirecting to and from files >> without going through Emacs. That could be done by creating a new kind >> of process object which is created by opening a file, and then that can >> be passed in in the way I describe above. > > Yes, something like that. > >> But to me that sounds somewhat unnatural for the process API. > > To me it sounds most natural. All of our APIs in this area are like > that. OK, that works for me. I guess it's not really different from the API I would have constructed for file descriptors. I can hack up some patches for this. Or maybe people have more thoughts on the appropriate API first? > Btw, running a pipe of processes raises another issue, unrelated to > file descriptors: we would need a way to make sure the processes do > not start running until all the redirections are set up, otherwise > some of them will die with SIGPIPE or somesuch. No, SIGPIPE will only happen when the read end of the pipe is no longer open anywhere. If a process is writing to a pipe for which the read end of the pipe has not yet been passed to a subprocess, that process will just block, since we will still have the read end of the pipe open in the Emacs process. We would only close the read end of the pipe after forking, and the fork will make a copy of the read end of the pipe so it will still be open even while the redirection is in process.