Tramp and concurrency (was: Please test the merge of the concurrency branch)

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

Ken Raeburn <raeburn@raeburn.org> writes:

>> If people have proposals what to change in Tramp wrt concurrency, please
>> say so. Of course I know that, for example, file copying shall not block
>> further Emacs use, but I'm still uncertain how to integrate this. As of
>> today, all callers of `copy-file' and friends do expect, that the
>> copying has finished once the function returns.
>
> Given that it’s an optional feature at this point (and not supported
> by every OS), I’d be careful in how you try to make use of it.
>
> In fact, Tramp is one of the areas where you might want to consider
> whether some, ah, defensive changes might be wise first.  For example,
> if I have a couple of threads invoking find-file in a package of mine,
> and both invocations have Tramp filenames, and the Tramp code has
> blocking calls (e.g., waiting for subprocess output) that result in
> thread switching, both threads could be trying to mess around with the
> same Tramp data structures and subprocess communications, with messy
> results.  Unless we want to tell people “don’t do file operations in
> more than one thread”, or “don’t do Tramp operations in more than one
> thread” (in which case people doing file operations need to check
> whether they’re local files?), maybe Tramp should do some locking
> internally.

Well, Tramp distinguishes between "inline methods" (all communication
goes over the same channel, like for "ssh"), and "external methods",
which invoke an own subprocess for data transfer, like for "scp". A
first candidate for concurrency would be external methods; switching
between processes happens there already.

And I agree that Tramp shall offer this as optional feature. This is
also a must, because Tramp supports also older Emacsen w/o concurrency.

> And what happens if I invoke “tramp-cleanup-all-connections” while a
> file-reading operation is in progress?

Don't know yet. Maybe all such functions in other threads must raise an
"interrupted" error, or so.

> Ken

Best regards, Michael.