https://forum.world.st/Working-with-weak-announcements-tp3305802p3306430.html
now the problem is how much time do you expect it may take to introduce ephemerons?
Else having well documented patterns is also important.
> On 14 February 2011 21:52, Esteban Lorenzano <
[hidden email]> 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.
>