About the non-use of Announcer in Bloc

2016-08-31 10:10 GMT+02:00 Glenn Cavarlé <[hidden email]>:

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.

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. 

this is really cool :)

Hi Stef,

here is the script I use:

| c1 c2 c3 n1 n2 n3 l1 l2 l3 |
c1 := c2 := c3 := 0.
n1 := (Announcer>>#announce:) ast.
n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ].
n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast ].
l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value.
l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value.
l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value.
[ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ].
(Duration minutes: 1) wait.
n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e removeLink: l3 ].
{ 'announce' -> c1. 'subscribe' -> c2.  'unsubscribe' -> c3 } inspect ] forkAt: Processor userBackgroundPriority

2016-09-01 9:28 GMT+02:00 Thierry Goubier <[hidden email]>:

Hi Stef,

2016-09-01 8:13 GMT+02:00 stepharo <[hidden email]>:

Hi thierry

I think that if we would have a tool to show us the activity I'm quite sure that we would find bugs

or mistaken behavior.

Yes. I did some checks on Morphic and AltBrowser after getting the numbers, to see if I wasn't

doing something wrong with my code.

could you send the scripts you did?

Later today. I don't have access now to the laptop where I did it.

Thierry

 

Stef


Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

No activity, empty desktop:
announcements            608/minute
subscribe add/remove        9/minute

Activity, AltBrowser:
announcements            1109/minute
subscribe add/remove        207/minute

Activity, Nautilus:
announcements            2488/minute
subscribe add/remove        716/minute

Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders.

Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements.

Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :

On 30 Aug 2016, at 5:16 , Thierry Goubier
<[hidden email]> wrote:


I have the same concern with an Announcer optimized for certain use
cases, in the fact that the announcer creator is the one choosing
the 'kind of' optimisation it would target, hoping that the
listeners will conform to that use case...

There simply is no silver bullet that will give unbeatable
performance in all scenarios; and focusing on improving one facet of
the default implementation will inevitably lead to either - the loss
of some important property (general thread-safety if removing the
mutex protection, ability to unsubscribe in handler if removing the
copy operation and extending the delivery mutex protection, etc.) -
greatly degenerated performance for another facet (like #remove for
OC's).

That said, the current implementation is very geared towards decent,
balanced subscribe/unsubscribe performance, at the expense of
delivery speed. I've said it before, and still think, that offering
at least one other implementation emphasizing delivery speed over
subscription/unsubscription performance, in the same way the original
implementation did (and/or changing the default Announcer to switch
between the two dynamically based on heuristics) *would* be a
valuable addition to the general library.

Cheers, Henry