#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
---------------------------------+--------------------------------------
Comment (by akaariai):
OK, this seems hairy. RLock doesn't work (I don't know why, but tests fail
all over the place).
Still, the basic problem is that it seems that just looping over
weakreffed receivers might end up cleaning the weakref, and that again
will lead to trying to take self.lock. We must use some sort of
concurrency control here, as otherwise we could end up caching receivers
that have been removed. Maybe there is some lock-free algorithm for
this...
I'll mark this accepted. I haven't reproduced the error, but in any case
tacking a lock in an action that is fired by garbage collector seems like
a seriously bad idea.
--
Ticket URL: <https://code.djangoproject.com/ticket/21952#comment:2>
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.1174c1e009804034475268314c546150%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
