matplotlib-devel Mailing List for matplotlib

Another common solution to this problem is to copy the list of callbacks 
before iterating over it.
Having a simple example would be helpful here so we can experiment with 
these alternate approaches.
Mike
On 10/16/2011 09:04 PM, to...@i3... wrote:
> Within matplotlib.cbook.CallbackRegistry both the connect() and process() methods check for dead references when called. If a reference is dead it deletes it from the callback list.
>
> I have found a situation where this presents a problem.
>
> First, a "button_press_event" calls the process method() which begins a loop over all of the callback items for this event. One of these items is a dead reference but appears late in the list. The first callback within the loop creates a new connection and calls the connect method. During this connect call the dead reference is deleted from the callback list. Then when it gets back to the loop within the process method the callback no longer exists in the list it is iterating over and there is an error thrown when it tries to delete the dead reference for the second time.
>
> The problem is coordination between these two places that both could potentially delete a dead reference to a BoundMethodProxy. In my case, because one loop has started ... the attempt is made twice ... and obviously the second results in an error.
>
> I could put together a simple example if needed to demonstrate the error.
>
> I think the easy way to handle would be to first call a method who's job is only to delete dead references. Then each method could call this first before handling the callbacks. This would keep the intermingling of the two loops that both check for dead references.
>
> Another (potentially more obscure approach) could be to just wrap the delete with a try/except - but this suffers from not fixing a bit of a design problem.
>
> There are likely more approaches to solving.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Within matplotlib.cbook.CallbackRegistry both the connect() and process() methods check for dead references when called. If a reference is dead it deletes it from the callback list.
I have found a situation where this presents a problem.
First, a "button_press_event" calls the process method() which begins a loop over all of the callback items for this event. One of these items is a dead reference but appears late in the list. The first callback within the loop creates a new connection and calls the connect method. During this connect call the dead reference is deleted from the callback list. Then when it gets back to the loop within the process method the callback no longer exists in the list it is iterating over and there is an error thrown when it tries to delete the dead reference for the second time.
The problem is coordination between these two places that both could potentially delete a dead reference to a BoundMethodProxy. In my case, because one loop has started ... the attempt is made twice ... and obviously the second results in an error.
I could put together a simple example if needed to demonstrate the error.
I think the easy way to handle would be to first call a method who's job is only to delete dead references. Then each method could call this first before handling the callbacks. This would keep the intermingling of the two loops that both check for dead references.
Another (potentially more obscure approach) could be to just wrap the delete with a try/except - but this suffers from not fixing a bit of a design problem.
There are likely more approaches to solving.