Hi, In both HandlerManager and SimpleEventBus, both adds and removes are buffered while events are firing. However, adds to not need to be deferred.
Especially since the firing lock is eventbus wide, I have gotten bit by this where in one event handler (say, presenter start), I added an event handler for an unrelated event, briefly later fired it, and did not see my new handler get called. Granted, it is a special case, but it caused me a lot of frustration. As a newbie it seemed like something that should "just work". Since then I've been using a hacked HandlerManager that always allows adds to be appended to handler lists. HandlerManager has the easiest fix--just don't cache the handler count while iterating. (And even this is optional, if count was cached, but adds still done directly, then my original scenario of adding a handler for an as-yet-unfired event would be fine.) SimpleEventBus would have to remove its iterators (I assume, otherwise they'd get a concurrent modification exception), and just use a counter based loop as well. Only removes really have to be deferred, because they would shift the handler list out from under any potential iterations. But appends are okay. I'd gladly file a bug and provide patches if given the nod. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
