WIP: Fix notification unsubscribe lock #294
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here is a description of the cause of this pull request (I will be referring to the bgapi backend).
Description of issue:
When the
unsubscribe
function tries to unsubscribe from a certain notification, it locks a thread lock withwith self._lock
. Theunsubscribe
function then calls a function which waits for a 'write confirmation' data packet from the Bluetooth client to confirm that the write to the notification configuration handler is successful. If a server is notifying the client at a fast enough pace, a notification packet will come it before the 'write confirmation' packet. That notification packet will then call the_receive_notification
function. That function can't run as the_lock
lock is locked up by thesubscribe
function. This results in a lockup, as the_receive_notification
function is trying to use a lock that is occupied and won't be released until thesubscribe
function receives a 'write confirmation' packet, which it can't as the packet handler is locked up by the_receive_notification
function.(Hopefully I got my point across and didn't create more confusion than before)
Fix:
A solution is to have the
_receive_notification
function check if either:_lock
lock is acquired by another function (What this PR currently does as of commit 60b7ed4)self._callbacks
array before thewith self._lock
line is called.What is the best way to approach this issue (or if there is another better way to)?