Re: [platform-ui-dev] Design Question About Listeners & Event Dispatchin

[Randy Hudson <hudsonr@xxxxxxxxxx>]

Generally there is nothing in the API
which suggests that this would fail. We just had this discussion (read
"complaint") on the GEF newsgroup.
http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg11536.html

But a related question is also interesting.
 If a listener is *added* during notification, should that listener
receive the notification, despite not having been a listener when the event
occurred.  I am 99% sure that the workbench relies on this behavior
from SWT.  SWT does not have either of the problems mentioned here
because they leave holes in their lists if you remove during notification.

It would be nice if there were a common
implementation for managing listeners in a safe and efficient way.  It's
possible to implement "copy-on-modify" such that additions/deletions
occur in constant time.

-Randy

Douglas Pollock <douglas.pollock@xxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

05/06/2005 02:43 PM

Please respond to
dpollock and "Eclipse Platform UI component developers list."

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	[platform-ui-dev] Design Question About Listeners & Event        Dispatching

My question is whether it should be expected that
the list of listeners can be 
modified while executing a listener.  Should we always design for
this case?  
In other words, should it be possible for a listener to add or remove a
listener while handling an event?


There is a lot of existing code of the following form, or similar but using
iterators.  In the case of iterators, a ConcurrentModificationException
will 
be thrown.  In the case of indexed access, subtle bugs can exist where
listeners are skipped or handled twice.

        if (activityListeners != null) {
            for (int i = 0; i < activityListeners.size();
i++) {
                ((IActivityListener)
activityListeners.get(i))
                    
   .activityChanged(activityEvent);
                
    }
                
}

If we write defensively, then we need to do a copy of some sort to avoid
corrupting the collection.

                
int commandListenersSize = commandListeners.size();
        if ((commandListeners != null)
                && (commandListenersSize
> 0)) {
            final ICommandListener[] listeners
= (ICommandListener[]) 
commandListeners
                    .toArray(new
ICommandListener[commandListenersSize]);
            for (int i = 0; i < commandListenersSize;
i++) {
                final ICommandListener
listener = listeners[i];
                listener.commandChanged(commandEvent);
            }
        }


Should we expend the effort to hunt down the places where we don't defend
against this case?  Or fix them on a case-by-case basis?



cheers,
d.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev