[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to avoid the user triggering "Forbidden reentrant call of Tramp"
Re: How to avoid the user triggering "Forbidden reentrant call of Tramp"?
Wed, 14 Apr 2021 13:48:50 +0200
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Hendrik Tews <firstname.lastname@example.org> writes:
>> 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
> 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
> Instead of throwing the error, with-tramp-locked-connection could
> wait with sit-for or accept-process-output until PROC is not
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,
Best regards, Michael.