[Pharo-project] 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.
Great work! I am so looking forward to use this :). Please keep us posted when we can play with it and how to load it. Cheers, Doru On 13 Mar 2011, at 10:48, Stéphane Ducasse wrote:
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.
-- www.tudorgirba.com "One cannot do more than one can do."
participants (3)
-
Henrik Sperre Johansen -
Stéphane Ducasse -
Tudor Girba