#21952: Deadlock while dispatching signals
---------------------------------+--------------------------------------
Reporter: edevil | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 1.6
Severity: Release blocker | Resolution:
Keywords: signal deadlock | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by akaariai):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I think we have to go with RLock (re-entrant lock) instead of Lock. What
is happening here is that for some reason GC decides to clear the weakref
version of the signal when looping over self.receivers in _live_receivers.
If this is something that is caused by greenlets or something that could
happen on pure CPython isn't clear to me.
The basic problem is that we are running somewhat complicated code (and
worse yet, code that requires the signal's lock) as side effect of garbage
collection. No good ideas of how to fix that...
This seems impossible to test, and RLocks should be safe here. So, maybe
the easiest way is to just change self.lock = threading.Lock() to
self.lock = threading.RLock().
--
Ticket URL: <https://code.djangoproject.com/ticket/21952#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.42a1263dc1c3fa3576f06f8321f54f13%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
