[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tramp and concurrency (was: Please test the merge of the concurrency bra
From: |
Michael Albinus |
Subject: |
Tramp and concurrency (was: Please test the merge of the concurrency branch) |
Date: |
Sun, 11 Dec 2016 16:14:48 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
Ken Raeburn <address@hidden> 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.
- Re: Concurrency has landed, (continued)
Re: Please test the merge of the concurrency branch, Daimrod, 2016/12/11