Re: Tramp and timers

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

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

Exactly.

> Every connection should have a lock.  Whenever the connection is "in
> use", we take the lock.

That's how I have implemented it. The lock is kept per (connection)
process object.

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

Locally, I have a half baken implementation for Tramp using threads. It
is stalled for the known reasons. When I will continue, I will care
about.

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

Good idea, I haven't thought about this. And maybe I can make this
already working now, because timers using Tramp shouldn't suffer from
the problems which have stalled current implementation, mainly
interactive I/O in different threads. Timers shall not interact with the
user.

Another idea for using threads in Tramp is 'vc-registered'. It is a
magic function, and Tramp has an own implementation.

> If they don't, then the risk getting `tramp-recursive-access`.

In my current implementation, I have declared a new standard error
'remote-file-error'. I don't believe, that the term "tramp" shall be
part of the name. And I do plan to use it also for other internal error
situations, that's why it shouldn't be restricted to
"recursive-access". Maybe this new standard error could also accumulate
the existing 'ftp-error' standard error symbol. At least, 'ftp-error'
shall have 'remote-file-error' as error condition.

> IIUC your proposal is quite similar to what I describe,

Yes. My implementation passes already the default test suite (a simple
"make -C test tramp-tests", and it even passes the notorious
'tramp-test43-asynchronous-requests' case - a test, which has been
disabled for years, because I couldn't bring it to fly :-)

I'll continue with regression tests (the "adb" method is hairy); I hope
to commit this later this week.

>         Stefan

Thanks for your review, and best regards, Michael.