Thomas Heller wrote:
>po...@or... (Patrick K. O'Brien) writes:
>
>
>>Drew Perttula <dr...@bi...> writes:
>>
>>
>>>I shall be testing the release23-maint cvs branch today. The
>>>upcoming 2.3.3 release claims to fix the bug.
>>>
>>>
>>Thanks, Drew. And if you've got a fix for dispatcher, or advice for
>>dispatcher users, that would be great.
>>
>>
>
>I can only guess what you're talking about since I haven't seen the
>message from Drew (was it not sent to the list? Or did I accidently
>delete it in the piles of spam I receive?).
>
>
It was sent. Tim's writeup was linked from Drew's email:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/gc_weakref.txt?rev=2.1&view=auto
From what I've seen, dispatcher is one of the more advanced uses of
weakrefs currently "in the wild", so we do seem to run into a lot of
problems with them :) .
>I was still using a hacked version of dispatcher from the cookbook,
>and my workaround for the crashes (once I discovered the reason) was to
>disable gc at the beginning of the weakref callback functions and enable
>it at the end again.
>
>
If I'm reading correctly you'd still have a chance of seg-faulting if
the callback was called after one of its referenced objects "went
insane" (in Tim's terminology). That is, you can wind up getting a call
to the callback where the callback and a referenced object are part of a
reference cycle and the reference object has already been finalised. In
this case (if I'm reading correctly), the gc has already done the damage
by the time your callback is called, so you can still wind up accessing
the insane object. Still, if it works for you, that's good :) . Just
don't be surprised if once in a while you see it blow up :( .
Have fun,
Mike
|
