Re: Remote asynchronous processes

[Philipp Stephani <p.stephani2@gmail.com>]

Am Di., 14. Apr. 2020 um 11:03 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:

> Philipp Stephani has shown some figures in the discussion
> mentioned above. Maybe he can explain more detailed which kind of
> performance requirements he has in mind, and the use case(s).

There are lots of different use cases. The broadest category that I
can think of is "processes started in the background to improve the
editing experience." This includes things like M-x compile, the VC
operations, etc. The immediate trigger for my request, however, was
Flymake. Flymake wants to start backends frequently and at arbitrary
times during editing. So starting (not completing!) a backend can't
block for more than a few milliseconds, as that would lead to
unacceptable editing disruptions. This immediately rules out anything
calling call-process, accept-process-output, sleep-for, etc., or
anything else that calls pselect. Remote Flymake backends are really
only possible using the suggested approach. Lots of other use cases
can benefit from it, too.
In summary, the basic requirement is "make-process must reliably
return within a few milliseconds."

>
> However, we will loose features of remote asynchronous processes. At
> least (and not comprehensive), processes started via make-process
>
> - are not checked for passwords or other interactive dialogues
> - do not not support multi-hops anymore
> - cannot be killed via interrupt-process (??? I'm not sure)
> - do not tell the remote tty
> - ...

These are typically irrelevant for the editing use cases I have in
mind. In particular, starting a Flymake backend couldn't ever prompt
the user; any prompt should be converted into a silent failure.