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

[Hendrik Tews]

Hi,

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

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

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

> What you could try is to use file notifications instead of calling

Thanks for the hint, but I don't think that file notifications
will work. I need to compare modification times of files that I
haven't encountered before, in the same way as `make' does.

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

This is not unfortunately not an option either. Theorem proving
is compute intensive. The application case for Tramp support in
Proof General is to access your big theorem proving server from
your desk or while traveling. 

Best regards,

Hendrik