Re: How to avoid the user triggering "Forbidden reentrant call of Tramp"?

[Michael Albinus]

Hendrik Tews <hendrik@askra.de> writes:

> Hi,

Hi Hendrik,

> in the application that I outlined in my previous email "optimize
> tramp for many start-file-process'es in parallel", Tramp
> functionality is invoked asynchronously from within a process
> sentinel. The functionality has been purposely moved into
> sentinels in order to keep Emacs responsive during the background
> compilation, similarly to M-x compile. However, when the user
> tries to open another file, maybe using completion, he possibly
> invokes Tramp while another synchronous Tramp call (maybe
> file-attributes), started from within some sentinel, is running.
> Consequently the "Forbidden reentrant call of Tramp" error is
> raised.
>
> How should I design my sentinel, such that this error is avoided?
> The source code hints to "connection buffers". How do I call
> file-attributes, such that it uses one connection buffer, while
> the user is doing file name completion, using a different
> connection buffer?

That's not possible. All synchronous remote operations use the *same*
process. file-attributes, and the operations serving file name
completion, are synchronous operations.

It is in general not a good idea to invoke synchronous Tramp operations
in asynchronously running functions like timers, process filters and
sentinels, event handlers. The Tramp manual mentions this in the FAQ
section.

What you could try is to use file notifications instead of calling
file-attributes. This changes your data flow from pull-baed (call of
file-attributes) to a push-based (handling of incoming events). Read

(info "(elisp) File Notifications")

The point is, that it works for both local or remote files. For remote
files it depends on the availability of either the "inotifywatch" or the
"gio" program on the remote machine. If you support mainly GNU/Linux,
there is no problem.

File notification is pretty reactive in the local case. In the remote
case, there is a short delay, but I have no data figures that I could
tell whether it prevents your use case. OTOH, if there is a slow
connection, calling file-attributes will be slow either.

There are also optimization possibilities. If you could arrange that all
files to be monitored are located in the same directory, you could
monitor that directory only.

> Thanks in advance,
>
> Hendrik

Best regards, Michael.