On 15 February 2011 18:52, 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. > > Ok how many weeks?
I have to read the paper about it to refresh my memory.. and then apply these concepts to squeak/cog vm reality :) > >> 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. >> > > > -- Best regards, Igor Stasenko AKA sig.
