Closed sergey-shambir closed 6 years ago
You are absolutely right.
I think the right think to do may be to just collect the callbacks to be called in a first pass, then release the lock and finally loop over the collected slots and call them one after another.
I worry that doing so may need some dynamic allocation to hold the list of slots, but the good news is that the contention on the lock is likely to drop a lot.
I pushed a fix and a unit test for this issue. Let me know if you think this is not sufficient.
Here library calls foreign callbacks under mutex lock:
Imagine that one thread connects to "signal1" own function "slot1" which fires "signal2". First, it locks "signal1" mutex, then attempts to lock "signal2" mutex.
Another thread connects to "signal2" own function "slot2" which fires "signal1". First, it locks "signal2" mutex, then attempts to lock "signal1" mutex.
In some cases, threads will enter into deadlock: thread1 always waits "signal2" mutex, while thread2 always waits "signal1" mutex.
Illustration: