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

[Hendrik Tews]

Hi Michael,

thanks for your quick answer.

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

Assume a library writer decides that he needs to call
file-attributes or delete-file in a sentinel or process filter.
There is no hint in the elisp manual that these functions might
transparently invoke Tramp and if he did not come across this
thread, it is unlikely that he will consult the Tramp manual or
check for remote file names.

With some bad luck, a user, that uses this library with remote
files might do remote file name completion just when the sentinel
or process filter runs, provoking the forbidden reentrant call.
The error is unexpected and will likely leave the library, the
user and his emacs session in a confused state behind.

> a locking mechanism shall be added by the caller.

There are two callers in the above example, the library which
calls file-attributes or delete-file and the user, who does file
name completion during find-file. I don't think the user should
get the burden of protecting himself against the error. If the
library writer is responsible for avoiding the error, then,
without support from Tramp, he can only advise all functions that
might call into Tramp and that might get invoked by the user
(such as find-file or some internal of it). I don't think this is
practical.

Therefore, the only solutions, that I see is that (1) the library
writer is told to not use functions such as file-attributes or
delete-file on remote files in sentinels or filters. Or (2), that
Trump supports the library writer in avoiding the interleaved
Tramp calls of the library and the user. A different idea for
this would be to expose a function for opening a separate process for
synchronous operations and an interface where the library could
tell Tramp to use that process for the next invocation of
file-attributes. The find-file invocation from the user would
stay unchanged, and therefore use the (different) default
process.

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

Right, I see this danger. But there is trouble already, and maybe
the library writer should get some support.

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

OK, too bad.

Best regards,

Hendrik