[Pharo-project] Working with weak announcements...
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? best, Esteban
good question :) On FHi,
I'm working with weak announcements,
good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level
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?
best, Esteban
On 14 February 2011 21:52, Esteban Lorenzano <estebanlm@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.
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. Stef On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote:
On 14 February 2011 21:52, Esteban Lorenzano <estebanlm@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.
On 15 February 2011 10:00, Stéphane Ducasse <Stephane.Ducasse@inria.fr> 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. 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@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.
Lol, good luck! Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 15, 2011 4:46 PM Subject: Re: [Pharo-project] Working with weak announcements... On 15 February 2011 10:00, Stéphane Ducasse <Stephane.Ducasse@inria.fr> 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. 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@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.
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@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.
On 15 February 2011 18:52, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <estebanlm@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.
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
Esteban Lorenzano -
Gary Chambers -
Igor Stasenko -
Stéphane Ducasse -
Stéphane Ducasse