Short summary of new announcement capabilities

> Barring a few update problems, they changes Igor and I made today should
> be ready for general review/inclusion shortly.
> Here's a few points about the most important differences to the current
> implementation:
> 1. Now supports action blocs with 0, 1 or 2 arguments (announcement and
> receiver).
> This should allows us to:
>    1.1 Write blocks with strict guarantees for expiry and removal
> without keeping strong references to announcers in subscriber, by using
> the announcer arg to unsubscribe if action is invalid. (Not very nice
> resulting code, but necessary if altering outside-accessible state)  
>    1.2 use suspendWhile: equivalent from blocks where announcer is not
> kept in context when such protocol is added.
>    1.3 Not use :ann argument for action blocks in which you don't
> really care.
>    1.4 Provide an upgrade path from events by replacing them with 0-arg
> MessageSend announcements under the hood if we want.
>        (Would requires some nasty bits with objects as announcers though).
>
> 2. Support weak subscriptions for message send type of announcement.
>     Block action requires ephemeron support in VM to correctly
> unsubscribe automatically, and trying to create them currently raises an
> error.
>
> 3. Reify Subscriptions (which are returned by #when:do: and friends),
> which can be made weak with #makeWeak.
>    However, for thread-safety reasons this is done using  
> #becomeForward:.
>     If weakness can be determined at subscription time, the recommended
> way would be to use:
>         announcer weak when:send:to:
>     The weak send creates a wrapper which will instantiate the
> subscription as weak from the get-go.
>
> 4. The SubscriptionRegistry is thread-safe, in the sense that add:
> remove: and deliver: are protected by a Monitor.
>    (so you can remove: in action block without a deadlock, see 1.1).
>    Rather than block for the entire deliver: process, we chose to only
> protect the copy of subscriptions.
>    This implies that the following may happen:
>        Thread 1 starts delivery of announcement.
>        Thread 2 interrupts after copy is created, then removes a
> subscription and carries on doing its stuff
>        Thread 1 resumes, and delivers announcement to remaining
> subscriptions, potentially including that removed by Thread2.
>        Don't think this is likely to be a common scenario where
> protecting the entire delivery would have made a difference.
>    If you think otherwise, and can provide a good use case, please
> speak up and we may change it.
>
> if you want to browse the changes, they are available for perusal in the
> changesets attached to:
> http://code.google.com/p/pharo/issues/detail?id=3814
> (Split in two to take care of migrating existing subscriptions)
> Don't try to load them though, as they depend on changes in other
> issues, and the comment changes cause errors.
>
> Feedback would be appreciated.
>
> Cheers,
> Henry
>
> PS. We forgot to include #on:do:for: & friends, which allow you to
> specify another subscriber than the object block belongs to.
> This is an oversight and will be corrected before inclusion. Just in
> case you were following Tudor's tweets and were wondering where they had
> gone.
>
>

> Thanks a ***LOT***
> It is really important for pharo.
>
> Stef
>
> On Mar 13, 2011, at 2:08 AM, Henrik Sperre Johansen wrote:
>
>> Barring a few update problems, they changes Igor and I made today should
>> be ready for general review/inclusion shortly.
>> Here's a few points about the most important differences to the current
>> implementation:
>> 1. Now supports action blocs with 0, 1 or 2 arguments (announcement and
>> receiver).
>> This should allows us to:
>>   1.1 Write blocks with strict guarantees for expiry and removal
>> without keeping strong references to announcers in subscriber, by using
>> the announcer arg to unsubscribe if action is invalid. (Not very nice
>> resulting code, but necessary if altering outside-accessible state)  
>>   1.2 use suspendWhile: equivalent from blocks where announcer is not
>> kept in context when such protocol is added.
>>   1.3 Not use :ann argument for action blocks in which you don't
>> really care.
>>   1.4 Provide an upgrade path from events by replacing them with 0-arg
>> MessageSend announcements under the hood if we want.
>>       (Would requires some nasty bits with objects as announcers though).
>>
>> 2. Support weak subscriptions for message send type of announcement.
>>    Block action requires ephemeron support in VM to correctly
>> unsubscribe automatically, and trying to create them currently raises an
>> error.
>>
>> 3. Reify Subscriptions (which are returned by #when:do: and friends),
>> which can be made weak with #makeWeak.
>>   However, for thread-safety reasons this is done using  
>> #becomeForward:.
>>    If weakness can be determined at subscription time, the recommended
>> way would be to use:
>>        announcer weak when:send:to:
>>    The weak send creates a wrapper which will instantiate the
>> subscription as weak from the get-go.
>>
>> 4. The SubscriptionRegistry is thread-safe, in the sense that add:
>> remove: and deliver: are protected by a Monitor.
>>   (so you can remove: in action block without a deadlock, see 1.1).
>>   Rather than block for the entire deliver: process, we chose to only
>> protect the copy of subscriptions.
>>   This implies that the following may happen:
>>       Thread 1 starts delivery of announcement.
>>       Thread 2 interrupts after copy is created, then removes a
>> subscription and carries on doing its stuff
>>       Thread 1 resumes, and delivers announcement to remaining
>> subscriptions, potentially including that removed by Thread2.
>>       Don't think this is likely to be a common scenario where
>> protecting the entire delivery would have made a difference.
>>   If you think otherwise, and can provide a good use case, please
>> speak up and we may change it.
>>
>> if you want to browse the changes, they are available for perusal in the
>> changesets attached to:
>> http://code.google.com/p/pharo/issues/detail?id=3814
>> (Split in two to take care of migrating existing subscriptions)
>> Don't try to load them though, as they depend on changes in other
>> issues, and the comment changes cause errors.
>>
>> Feedback would be appreciated.
>>
>> Cheers,
>> Henry
>>
>> PS. We forgot to include #on:do:for: & friends, which allow you to
>> specify another subscriber than the object block belongs to.
>> This is an oversight and will be corrected before inclusion. Just in
>> case you were following Tudor's tweets and were wondering where they had
>> gone.
>>
>>
>
>