Re: Tramp and timers

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Tramp is plagued since ever with timers, which run while Tramp is
> performing accept-process-output. If such a timer runs an operation
> which includes also a remote file operation, it ruins Tramp's current
> process handling. See the discussion at
> <https://lists.gnu.org/archive/html/tramp-devel/2020-12/msg00003.html>
> for a recent problem.

Here's my take on it (I'm not familiar enough with the code to be sure
it's workable, so it's more like a backseat driver's design, so feel
free to ignore):

I think it should be OK for the timer to access a Tramp file on host
A while we're in the middle of a Tramp access to a file on host B.
So the interference should be detected "per connection" rather than
globally.

Every connection should have a lock.  Whenever the connection is "in
use", we take the lock.  This is also useful in the case of the use
of threads.  When we try to take the lock and it's already taken by
another thread, we should just wait (or rather, the lock should do that
for us), but if it's already taken by the current thread then we should
instead signal an error like `tramp-recursive-access`.

Timers should arguably each run in their own thread.  Of course, they
(currently) don't, but if a timer function wants to use Tramp files,
then it should start by delegating its job to a thread (we should
probably have a standard function like `run-with-timer-concurrent` which
calls the timer function in a separate thread).  If they don't, then the
risk getting `tramp-recursive-access`.

IIUC your proposal is quite similar to what I describe,


        Stefan