And now question is why SubscriptionRegistry manages subscriptions as
IdentitySet instead of OrderedCollection?

2016-08-29 18:36 GMT+02:00 Denis Kudriashov <[email protected]>:

> And expenses to deliver announcement caused also by protection and usage
> of IdentitySet.
> Also in announcements we first collect all subscriptions with interest to
> separate collection and only after we iterate and process given
> announcement.
>
> But in Bloc you use #select:thenDo: method instead. It is unsafe because
> event handlers can be modified during delivering (by producing new
> subscriptions or by unsubscribing inside handlers).
>
> So if you want to address it (and I sure you do) it will lead to same code
> and performance of announcements.
>
>
>
>
> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov <[email protected]>:
>
>> Thank's.
>> I try tests for subscribing and what I found is:
>>
>> Main problem that subscriptions inside SubscriptionRegistry are managed
>> as IdentitySet which of cause much slower for addition then
>> OrderedCollection. We probably could use OrderedCollection here because
>> items are always created on fly and identitySet has no sense.
>>
>> Another problem is access protection by mutex (semaphore) which make it 3
>> times slower.
>>
>> So with OrderedCollection and disabled mutex performance for subscribing
>> is same.
>>
>> I pretty sure that protection is required for Block handlers too.
>>
>> 2016-08-29 17:18 GMT+02:00 Glenn Cavarlé <[email protected]>:
>>
>>> Ha...  tag doesn't work...
>>>
>>> You can load Bloc and show the tests using this script:
>>> Gofer it
>>>     smalltalkhubUser: 'Pharo' project: 'Bloc';
>>>     configuration;
>>>     loadDevelopment.
>>> Gofer it
>>>     smalltalkhubUser: 'Pharo' project: 'Bloc';
>>>     package: 'Bloc-Tests';
>>>     load.
>>> BlAnnouncerVsBlEventRegistryTest browse
>>>
>>>
>>>
>>>
>>> -----
>>> Glenn Cavarlé
>>> --
>>> View this message in context: http://forum.world.st/About-th
>>> e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at
>>> Nabble.com.
>>>
>>>
>>
>

Reply via email to