Re: Using file descriptors in Emacs

[sbaugh]

Eli Zaretskii <address@hidden> writes:
>> From: address@hidden
>> Date: Sat, 10 Sep 2016 10:28:44 -0400
>> Two features that I would like to add to eshell (or some shell in Emacs)
>> that I believe will require the ability to directly manipulate file
>> descriptors:
>> 
>> - Piping data to and from processes without that data round-tripping through
>> Emacs, which is necessary if I want to write a pipeline processing any
>> significant amount of data (which I frequently do in even casual shell
>> use)
>> - Redirecting higher file descriptors than 0/1/2 (that is, when creating
>> a process, before forking, use dup2 to rearrange what file descriptors are
>> in what slots)
>
> It sounds like none of these two features need file descriptors to be
> exposed to Lisp.  Both of these sound like extensions of
> start-process, and the descriptors could be dealt with entirely on the
> C level, as applications shouldn't care about them.  Am I missing
> something?

What kind of API based on extending start-process would allow these
features to be used in full generality?

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.

But to me that sounds somewhat unnatural for the process API. Are those
the kind of extensions you were envisioning? Such extensions would work
fine for my purposes.