>>
>>> 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 <[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.
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>