Problem with some event notification... [message #176810] |
Tue, 12 April 2005 03:43  |
Eclipse User |
|
|
|
I don't have an account for bugzilla so i'm reporting it here. Would
someone be so kind to put it in... Thanks.
It seems that some fireXXX methods in GEF and Draw2D has some issue with
sending out notification IF the notified object manipulates the listener
list during a notification. For example as a response to an
ancestorRemoved notification it tries to remove itself (or any other
listener added before itself) from the ancestorListener list. This is
caused because AncestorHelper.fireAncestorRemoved is iterating over the
listener list using a for loop instead using an iterator. This causes
that after it removed itself from the list, the next listener on the
list will not be called by the fireAncestorRemoved action (as the whole
array will be shifted down by one). Please check and change the
implementation to use iterators.
Affected classes with similar problems:
Draw2d: AncestorHelper, ButtonGroup, UpdateManager
GEF: PaletteViewer, AbstractEditPartViwer
Thanks, Rudolf
|
|
|
|
|
|
|
Re: Problem with some event notification... [message #177218 is a reply to message #177088] |
Tue, 12 April 2005 23:36  |
Eclipse User |
|
|
|
Randy Hudson wrote:
>>Wouldn't the iterator have the same problem? You can only invoke the
>
>
> Right, you'd get a ConcurrentModificationException.
>
>
>>iterator's remove method to guarantte anything.
>>
>>What do other frameworks do? I believe SWT loops through using an index
>>as
>>well. So does PropertyChangeSupport.
>
>
> SWT leaves holes (null) in its arrays to prevent the index from getting off.
> AWT uses a special binary tree. JFace and others use copy-on-modify.
>
> I like AWT's implementation the best, but someone would have to re-implement
> the datastructure in a clean-room style.
>
>
You guys are right. I just checked a little deeper and it seems that
PropertyChangeSupport is using a copyOnModify too (and iterates with
indexes). So the problem is not really how the iteration is done, but
rather the underlying data structure. The cleanest way would be to have
an immutable data structure to store the listener list. I think a simple
copyOnModify would do here...
|
|
|
Powered by
FUDForum. Page generated in 0.06934 seconds