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."
