util: CallbackManager: add comment how unregister_callback could race
What changed, and why it matters
This commit only adds a comment explaining that a race condition is theoretically possible in the callback manager. It does not change any code behavior, fix a bug, or introduce a vulnerability. No action is needed beyond normal awareness.
No immediate action. Treat as a non-security documentation-only commit. If concerned, monitor future commits that actually address the race condition described in the comment.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff adds a FIXME comment in electrum/util.py’s CallbackManager.unregister_callback() noting that if trigger_callback() was just called for the same callback, the callback could still execute after unregister_callback() returns. No code logic is modified; the lock behavior and method implementation remain unchanged. The commit is purely documentary.
Changed components
electrum/util.pyCallbackManager.unregister_callback()Inspect captured patch +2 / −0
diff --git a/electrum/util.py b/electrum/util.py
index afbf95d..bc870ea 100644
--- a/electrum/util.py
+++ b/electrum/util.py
@@ -2013,6 +2013,8 @@ class CallbackManager(Logger):
self._wcallbacks[event].add(wcb)
def unregister_callback(self, cb: Callable) -> None:
+ # FIXME if trigger_callback() was just called for this cb, it could race so that
+ # the cb gets code exec *after* unregister_callback() returns.
wcb = self._wcb_from_any_callback(cb)
with self.callback_lock:
# note: ^ callback_lock needs to be re-entrant, as we can now trigger __del__, which also takes the lock
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.