[Pharo-project] Working with weak announcements...

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Feb 15 18:52:10 CET 2011


> 
>> 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 <estebanlm at gmail.com> 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.
> 





More information about the Pharo-project mailing list