On 15 February 2011 10:00, Stéphane Ducasse <[email protected]> wrote: > Igor > > now the problem is how much time do you expect it may take to introduce > ephemerons? > Else having well documented patterns is also important.
I think it is relatively easy to modify VM , since it touching only GC related stuff. And also there is already an implementation somewhere made by Ian.. which can be used as reference. > > Stef > > > On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote: > >> On 14 February 2011 21:52, Esteban Lorenzano <[email protected]> wrote: >>> Hi, >>> I'm working with weak announcements, trying to make it work, and I have a >>> problem in #on:do: protocol (or #when:do:) >>> I try to explain: >>> >>> This method receives a block, not an object/selector, so I can't create a >>> WeakMessageSend which is the appropriate message to handle in other cases. >>> Well, the real question is... how can I produce a "Weak BlockClosure >>> reference" who can die if receiver dies? >>> I tried some hacks (really ugly hacks, btw), but fail completely. >>> Any idea? >>> >> >> Don't even try doing it until we will have ephemerons support at VM side :) >> >> I explained this few days ago to Stephane, and also i mentioned about >> this maybe half of year ago when i took a look at announcements. >> >> With ephemerons you can have: >> - reference a block strongly only if subscriber , which held weakly is alive. >> >> Once subscribed dies, you start referencing block weakly. >> >> In terms on GC it means, that during mark phase, you are visiting a >> references which reachable through block closure only if your >> subscriber are already marked as 'live'. >> >> So, this means that you can do weak subscriptions like following: >> >> >> self weakOn: Foo do: [:announcement | self bar ]. >> >> A 'self' is a subscriber. But if you create a subscription from a pair of: >> <subscriber> and <block> >> without using ephemerons you should make sure that reference to >> subscriber are not reachable through given block. >> Otherwise, a weak reference become strong one, because you referencing >> a block strongly and therefore subscriber too, >> since block referencing subscriber through one of its vars. >> >> So, without ephemerons you have to invent some workarounds by >> rewriting above code with something like: >> >> >> self weakOn: Foo do: [:announcement :myself | >> myself bar >> ]. >> >> in the above, a block no longer referencing receiver (a subsriber), >> and instead it will be passed as extra argument >> to the block. >> >> ( except that still, you will have a problem, if closure keeps a >> reference to home context, which in own turn referencing subscriber >> through context's receiver.. so without emphemerons you should be >> really careful) >> >> And of course, i think that the usefulness of Announcements is quite >> limited without proper weak subscription support, >> because weak subscriptions makes things a lot more easier: you don't >> have to explicitly unsubscribe some object, once you no longer using >> it , >> which as to me means that about 99% of all subscriptions in system >> will be weak ones , simply to prevent potential problems with hanging >> references, and because you don't have to worry about unsubscribing. >> >> And of course, without weak-block subscriptions, the ease of use of >> subscription mechanism is a bit limited. >> So, instead of writing simple and cool: >> >> self weakOn: Foo do: [:announcement | self bar ]. >> >> >> you must do more elaborate (and IMO less elegant) >> >> self weakOn: Foo send: #handleFooAnnouncement: . >> >> and then in #handleFooAnnouncement: you making 'self bar' >> >> P.S. the #weakOn: ... is not part of Announcements protocol , it is >> just an example of 'meta-message' to reveal an intent to create a weak >> subscription to some announcer by using receiver as a subscriber. >> >> >>> best, >>> Esteban >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig.
