I don't know if this is an improvement. You seem to have added a busy-while-loop. Study condition objects to remove that busy-while-loop.

That said, why not put access to documents, and mutation of documents, under a simple threading.Lock? clangd applies this idea and it works fine:

https://github.com/llvm/llvm-project/blob/master/clang-tools-extra/clangd/DraftStore.h
https://github.com/llvm/llvm-project/blob/master/clang-tools-extra/clangd/DraftStore.cpp

@rwols We didn't took Locks on this one, as handling them may lead to deadlocks or livelocks. The implementation here is equivalent to actors and processes, as they are implemented on Erlang. We use a queue as a mailbox to send a message and then wait for the response, this way, we ensure that no process gets a deadlock

If you ensure a lock is only used from within the methods of a class like a DraftStore, and you make sure that class doesn't call its own methods, then I don't know how one would cause a deadlock.

Actually, acquiring a lock is equivalent in some sort of sense to wait for a message to arrive. Also, by using Actors, we don't have shared state anymore, this any other process cannot modify values directly without passing through the actor. Coming from the Erlang world, it seems more reasonable to use Actors and messages for handling concurrency, rather than locks or semaphores

by using Actors, we don't have shared state anymore, this any other process cannot modify values directly without passing through the actor.

All I see is an extra threading.Thread for no real reason, and a busy while loop.
The queue.Queue makes use a threading.Condition and threading.Lock, so this seems like using a lock with extra unnecessary steps.

@rwols, if you disagree with @andfoy and can provide the implementation you'd like to see, you're welcome to open a new PR about it. Otherwise we'll go with his.

I can only give advice. I don't have the time to delve into more open-source codebases. I fear that the unnecessary complexity will not make pyls easier to maintain. But you are of course free to merge this.

@andfoy, please solve the merge conflicts in this PR.