[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tramp and concurrency (was: Please test the merge of the concurrency bra
Tramp and concurrency (was: Please test the merge of the concurrency branch)
Sun, 11 Dec 2016 16:14:48 +0100
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
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.
Best regards, Michael.
Re: Please test the merge of the concurrency branch, Daimrod, 2016/12/11
- Re: Concurrency has landed, (continued)