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

[Michael Albinus]

Hendrik Tews <hendrik@askra.de> writes:

> Hi Michael,

Hi Hendrik,

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

I have been silent for some days, because I try to find a satisfying
solution. Well, the thread-safe code is still in Tramp. What hinders to
use it is the problem of handling the user interface with threads in
Emacs.

This doesn't happen in your case. A simple file-attributes or
delete-file in a process sentinel is not expected to interact with the
user. So we could run (a part of) the process sentinel in an own
thread. Tramp's internal mutex should avoid the problem of reentrant
Tramp function calls. Whichever thread (the main one, or the process
sentinel) reaches the Tramp mutex has to wait, until control is given.

I will try to implement something like this, and likely I will ask you
to test in your environment. Would this be OK?

> Best regards,
>
> Hendrik

Best regards, Michael.