Re: Please test the merge of the concurrency branch

[Ken Raeburn]

On Dec 11, 2016, at 04:11, Michael Albinus <address@hidden> wrote:

> Ken Raeburn <address@hidden> writes:
> 
>> The branch builds & runs fine for me on Mac OS X 10.11.6 (i.e., one
>> major release out of date).  Only tested with a few hours of normal
>> code editing work locally and via TRAMP so far though.
> 
> When time permits I'll check how Tramp could profit from the
> concurrency. First I'll release Tramp 2.3.1, so it might still take a
> couple of weeks.

There are still some basic bugs to work out…

> 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.  
And what happens if I invoke “tramp-cleanup-all-connections” while a 
file-reading operation is in progress?

There are probably other parts of the Lisp library in a similar position, but 
the ones coming to mind offhand would probably generally be used in more direct 
fashion, whereas Tramp often hides under the normal file abstractions.

Ken