Re: Please test the merge of the concurrency branch

[Eli Zaretskii]

> From: Ken Raeburn <address@hidden>
> Date: Sun, 11 Dec 2016 08:54:52 -0500
> Cc: Eli Zaretskii <address@hidden>,
>  Tom Tromey <address@hidden>,
>  address@hidden
> 
> 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 synchronization facilities to take care of these.  And each
thread can have its local bindings of the same variables, which also
could help.

But yes, making a large package such as Tramp threads-aware will
probably take some work.