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

[Michael Albinus]

Hendrik Tews <hendrik@askra.de> writes:

> Hi,

Hi Hendrik,

>> That's not possible. All synchronous remote operations use the *same*
>> process. file-attributes, and the operations serving file name
>> completion, are synchronous operations.
>
> OK, but this implies that sentinels, process filters and timers
> must not use all the functions listed in section 25.12 "Making
> Certain File Names Magic" unless they verify that the respective
> path' are not handled by Tramp. I am not sure this is feasible
> and I haven't seen such a warning in the elisp manual.

"must not use" is too hard. But there could be concurrent situations
like you have observed, and this is said in the Tramp manual.

>> 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.
>
> I haven't found this point in the manual. I only found that the
> filter or sentinel, which is involved when the "reentrant call"
> error is signaled, should be fixed. I assumed the fix is to tell
> Tramp to use a different connection buffer or to acquire some
> lock, that serializes all synchronous operations.

It is not explicitly phrased in the manual, yes. Perhaps this shall be
improved.

> Instead of throwing the error, with-tramp-locked-connection could
> wait with sit-for or accept-process-output until PROC is not
> locked.

No. Tramp is a dumb library, and it runs whatever it is said to run. It
shouldn't add own intelligence, this is always good for trouble. Such a
locking mechanism shall be added by the caller.

Two years ago, I've started to make Tramp thread-safe. By this, Emacs
threads could be used for remote file operations. This wouldn't improve
performance (there could be only one Emacs thread at a given time), but
its mutex mechanism could avoid the reentrant Tramp function calls.

Unfortunately, this project is stalled due to some blocking problems,
mainly bug#25214. This is not a Tramp specific problem, but a general
one. I have no idea, how to continue until this is solved.

> Best regards,
>
> Hendrik

Best regards, Michael.