Re: Using file descriptors in Emacs

[sbaugh@catern.com]

Eli Zaretskii <eliz@gnu.org> 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.