emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remote asynchronous processes


From: Philipp Stephani
Subject: Re: Remote asynchronous processes
Date: Fri, 7 Aug 2020 18:28:59 +0200

Am Fr., 31. Juli 2020 um 12:24 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Felipe Lema <felipelema@mortemale.org> writes:
>
> > Hello, there (I hope I'm replying correctly)
>
> Hi Felipe,
>
> Yes, that's the correct reply. And I'm happy that you did. Since there
> hasn't been any response for months, I am closed to throw the code away.

Please don't! Sorry for not responding earlier, I'm definitely still
interested in this.

>
> > I've tried this patch for async processes and, given that I deal with
> > far away servers that have a significant delay in answering queries, I
> > find this most useful. It cuts starting processes from about 5s to less
> > than 1s.
>
> I'm still undecided how to integrate it into Tramp. Since there are some
> restrictions (for example, it must be password-less), I fear a rise of
> fault reports ...

I guess it should be opt-in since whether or not such an approach can
be taken depends on how the process is to be used (background vs.
foreground, interactive vs. batch, advisory vs. mandatory, ...).
Ideally this would be an optional parameter to `make-process', but I
guess that's infeasible, so I guess either a special filename syntax
("fast-ssh:..."?) or a dynamic variable (not a customization option)
would be the next best approach.


> > If this is not feasible, then I can manage with this "non-checks-just-
> > run-this-command-as-is" approach.
>
> If integrated, it must be optional per connection. There might be remote
> hosts which could be treated this way; and other hosts which might not.

It would definitely be helpful to select the optimized behavior on a
per-host basis, and/or allow users to enable it by default if
feasible. I'd assume that nowadays many of the backwards-compatibility
workarounds are no longer required, and TRAMP could assume (at least
on an opt-in basis) that the optimal way "just works."



reply via email to

[Prev in Thread] Current Thread [Next in Thread]