-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Library is not thread-safe: deadlock can happen #2
Comments
This sounds more like a "design" problem in your application which will always lead to deadlocks when using locks / mutexes. If |
Code above just shows the issue; of course, in real code there will be conditional execution and more levels of indirection, so no endless loops will appear. |
I have added a "Known Issues" section to the README mentioning this potential deadlock. |
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.
The text was updated successfully, but these errors were encountered: