Le 31/8/16 à 11:23, Denis Kudriashov a écrit :
2016-08-31 10:10 GMT+02:00 Glenn Cavarlé <[email protected]
<mailto:[email protected]>>:
Hi all (I was out for some days),
Hi Glenn
What i see is that Bloc EventRegistry:
1) is not thread safe (no mutex + #select:thenDo:)
2) doesn't allow handler removal from the handler list currently
used in the
thenDo: loop
3) is used specifically for a one-to-many communication (1
BlElement -> X
handlers)
The (1) doesn't seem to be a problem in Bloc during UI event
processing
because a new event handler, even if it is added from another
thread, would
be taken into account for the next event.
Problem that concurrent modification of OrderedCollection could just
fail. You will got debugger.
I note that it is really not
recommended (at all) to update an UI element elsewhere than in the
UI thread
and it is like that in all other UI frameworks i know.
Does it means that I should not subscribe on UI events from different
(not UI) processes?
How to do this if it is needed?
Should I always put subscription code into #defer: message (analogue)?
In that case what to do if I need to be sure that I really subscribe
on event and only after this continue my business logic process?
The (2) is a very specific use case and i don't know if it is a
real need in
Bloc because this implies that an element has 2 handlers for the
same event
and one of them has to remove the other before it is executed and
during the
same event processing (maybe more a conception issue than a common use
case...). In other cases, no problem for handler removal.
Very simple example: I want one shot handler for MouseMove to
highlight element once to see that my mouse was moved around.
So my handler will highlight target element and unsubscribe it
immediately.
Problem that if you do it on OrderedCollection during iteration you
could skip one of the handlers. And probably some failures are also
possible (debugger again).
Of course you could say users do not do all of this. But what the
alternative? And if people will do this by "incident" it will be very
difficult to discover reasons.
But maybe i miss some specific cases in (1) and in (2).
To me, Announcer is really usefull and efficient when it is used
as an event
bus that can be shared between multiple objects.
For instance, it seems to be useless to use an Announcer in
NewValueHolder
because it cannot be shared and it is only used internally to register
handlers and to propagate only the same event (ValueChanged) to
them. What
is the gain of using a full featured Announcer in this case?
But in practice we never share any announcer instance.
Really? You lost me on that sentence. SystemAnnouncer current is shared
by all the tools no?
We always hide it inside owner object. ValueHolder is not specific
example.
Also ValueHolder is kind of active model for UI application which
could be shared between different views. And when it will be modified
in one view another view will be updated automatically.
In Bloc the constraint is to propagate more than 2000
events/second without
to decrease fps, so we cannot afford to x4 the time to process
events even
if Announcer is safer and better tested.
I wondering what the source of this constraint? Does Morphic follows
it? I guess not, but all Pharo works quite well with it.
