Thanks, that's a bit better. It still isn't clear why you needed to change Lock to RLock, which I really think deserves explanation (I would have asked to include that to the commit message had this been a PR).

Yeah, sorry for not creating a PR for this one - that would be the correct way to clarify this properly, but since there was a previous agreement about move these "Lock" to "RLock" I simply went ahead without PR.

Let me bring some context here as this is something Victor and I already discussed and agreed in the past.

The reason that motivated to use "RLock" here are basically the same that also motivated to use "RLock" here as well for a similar lock that we introduced: https://github.com/openSUSE/salt/pull/497

Basically, during our investigations around the logging and import deadlocks that we have been experiencing around "salt-ssh", we introduced different locks to prevent the possible deadlocks to happen. We figured out that introducing a normal "Lock" will cause an extra deadlock under certain stack scenarios (particularly when running salt-ssh via salt-api), where a same thread is acquiring the lock multiple times.

We decided it was reasonable to introduce "RLock" instead "Lock" for this locks we introduced. While we didn't change this one lock to "RLock" in 3004, it seems all the lazyloader / salt-api / salt-ssh / multiprocessing / threading magic is making to hit the deadlock for this one in 3005.1.

I hope this provides enough context around the motivations of this SR, and sorry again for now going via PR workflow on this one.

ok, thanks for the clarification. I guess hope we can drop these patches soon after upstreaming them.