> >> 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.
Ok how many weeks? > 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. >
