[Pharo-project] About announcements
renggli at gmail.com
Mon Jan 2 16:12:32 CET 2012
Ok, first of all I did not know who wrote the code. I was just fixing
some of my code that suddenly broke and was astonished what the
announcer all does when stepping through the announcement procedure
with the debugger ...
>>> 3. It enters a critical section of a monitor: This is rarely useful
>>> and the slowest kind of concurrency control available in Pharo (a
>>> Mutex would be enough for what it is used for, and instantiate
>>> multiple semaphores and queues), and btw the lazy initialization of
>>> the monitor is the prime example of a race condition.
>> agreed here. I would even leave a semaphore.
>> I think it is overlooked by Henrik.
>> It also don't needs a lazy initialization in #protected: , since in
>> #initialize it can just create a ready for use fresh
>> synchronization object.
A semaphore might block, because an announcement could register
another announcement. So probably the Mutex would be the right thing
>>> 4. It creates a copy of the collection of all the subscriptions: This
>>> is rarely useful and wouldn't be necessary if an immutable data
>>> structure was used.
>> propose better solution how to deal with situation when during
>> handling an announcement,
>> your handler unsubscribing from announcer.
Array. Slower for registration, but faster at announcing (the common operation).
>>> 5. It iterates over all announcements, it doesn't even try to group
>>> announcements of the same kind.
>> it is pointless to group them, and makes no real difference.
>> Because announcer doesn't knows what kinds of announcements will be
>> and it knows only about subscriptions.
>> Suppose i have a subscription to Announcement. And i announcing
>> AnnouncementA (a subclass of it).
Fair enough, probably it doesn't matter.
>>> 7. It then tests each announcement if it matches, again it doesn't
>>> even try to group the announcements of the same kind. Aside, the match
>>> test was changed so that it doesn't allow instance-based announcements
>>> anymore, breaking some of my code.
>> what is instance-based announcements?
If you have a client with 1000 different possibly dynamically changing
properties and you want a way to register for announcements of a
single property. The current implementation forces you to create a
class per property, previously you could fake a "kind of
announcements" with an instance.
>> you can use any object as a subscription selector, just make sure it
>> understands #handles: message.
No, because the Announcement>>#handles: takes a class, not an instance.
>>> 9. It then culls the announcement and announcer into the block. Not
>>> sure why the announcer is useful, after all the block was registered
>>> with the announcer at some point.
>> cull there is for passing optional arguments.
I didn't complain about #cull:, but about the useless announcer passed in.
Now for me you don't need to change the semantics of the Pharo
Announcements again. Now for my code I will just use my own
implementation that has exactly the behavior and performance
characteristics I need.
More information about the Pharo-project