Re: Remote asynchronous processes

[Michael Albinus]

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.

> 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 ...

> While this looks promising, I was also wondering about an alternative
> solution.
>
> Instead of sending-and-waiting-for commands, can't these results be
> stored in memory? That way tramp-sh can construct the "command to be
> sent" /without/ doing queries. If necessary, the results stored in
> memory can be updated frequently in the background. Maybe they can even
> be persisted for future use (using the `persist` package).

Tramp uses a cache. For every needed information it checks, whether it
is already in the cache. If not, a command is sent remote in order to
gather that information, and the result is cached again. You can see the
cache in `tramp-cache-data'.

This cache has a timeout, defined in `remote-file-name-inhibit-cache'.
The default value is 10 seconds for evry singla data. You might increase
the value (or set it to nil). This shall enable Tramp to use more cache
values.

> 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.

> Gards

Best regards, Michael.