[Pharo-project] Destiny of changed:/update:
Will changed:/update: disappear and be totally replaced by Announcements? I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little. -- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I suggest to keep it. It's lightweight solution for problems where events/announcement are overkill. Noury -- http://twitter.com/#!/NouryBouraqadi On 26 déc. 2011, at 14:43, Sean P. DeNigris wrote:
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that. In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed. Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stef, I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained?? I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that. In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed. Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained?? I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking. Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that. In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed. Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Levente, Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained?? I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking. Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that. In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed. Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing. I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained?? I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking. Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that. In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed. Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
That's not how ephemerons work, and they also get finalized. Both of you may be right... On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may be right...
Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project@lists.gforge.inria.fr; andres.valloud@gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may be right...
Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase. Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable. What else? weak set? again, put a wrapper around it and you got thread-safety. And what is 'self-repairing'? Can you explain what is it? -- Best regards, Igor Stasenko.
He might imply "any finalization process that runs on the weak collection after the objects are collected must be thread safe", which seems reasonable. You may get away with free "atomic" finalization if you have a finalization queue... but not always. For example, what happens if the finalization queue contains the weak array w (because the GC nilled some of w's slots), then the image starts finalizing w but the process has a DNU of some sort so it stops... if finalization is robust enough, then it will continue finalizing. Then you get another GC, w gets added to the finalization queue again because some other of its slots got nilled, and then the finalization is kicked off on w *again* while the first one is hung with the debugger open... On 12/27/11 2:39 , Igor Stasenko wrote:
i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase.
Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable.
What else? weak set? again, put a wrapper around it and you got thread-safety.
And what is 'self-repairing'? Can you explain what is it?
-- Best regards, Igor Stasenko.
To clarify... where is says "if finalization is robust enough, then it will continue finalizing", it means "if [the] finalization [process that kicks off finalization on individual weak arrays by draining the finalization queue] is robust enough [so that the hang in w's finalization doesn't bring down the whole thing], then it will continue finalizing [other objects]". On 12/27/11 3:47 , Andres Valloud wrote:
He might imply "any finalization process that runs on the weak collection after the objects are collected must be thread safe", which seems reasonable. You may get away with free "atomic" finalization if you have a finalization queue... but not always. For example, what happens if the finalization queue contains the weak array w (because the GC nilled some of w's slots), then the image starts finalizing w but the process has a DNU of some sort so it stops... if finalization is robust enough, then it will continue finalizing. Then you get another GC, w gets added to the finalization queue again because some other of its slots got nilled, and then the finalization is kicked off on w *again* while the first one is hung with the debugger open...
On 12/27/11 2:39 , Igor Stasenko wrote:
i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase.
Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable.
What else? weak set? again, put a wrapper around it and you got thread-safety.
And what is 'self-repairing'? Can you explain what is it?
-- Best regards, Igor Stasenko.
On Tue, 27 Dec 2011, Andres Valloud wrote:
He might imply "any finalization process that runs on the weak collection after the objects are collected must be thread safe", which seems reasonable. You may get away with free "atomic" finalization if you have a finalization queue... but not always. For example, what happens if the finalization queue contains the weak array w (because the GC nilled some of w's slots), then the image starts finalizing w but the process has a DNU of some sort so it
The finalization process in Pharo (and Squeak) only handles WeakRegistries. So your example is only theoretic, because the finalization process will never touch WeakArrays.
stops... if finalization is robust enough, then it will continue finalizing. Then you get another GC, w gets added to the finalization queue again because some other of its slots got nilled, and then the finalization is kicked off on w *again* while the first one is hung with the debugger open...
In Pharo you get a debugger when the finalization process runs into an error, in Squeak (just like in Java), the error is ignored. Levente
On 12/27/11 2:39 , Igor Stasenko wrote:
i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase.
Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable.
What else? weak set? again, put a wrapper around it and you got thread-safety.
And what is 'self-repairing'? Can you explain what is it?
-- Best regards, Igor Stasenko.
The short answer is "look at other dialects." Pharo's weak collections replace objects with nil. Dolphin's completely "forget" the object. It also does a robust job of handling the trickier side of finalization, such as the fact that an object is allowed to rescue itself at the last minute. All of this put together is what I mean by "thread safe and self-repairing." See it done well, and Pharo looks bad by comparison. I have put wrappers around the weak collections. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Tuesday, December 27, 2011 5:39 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase. Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable. What else? weak set? again, put a wrapper around it and you got thread-safety. And what is 'self-repairing'? Can you explain what is it? -- Best regards, Igor Stasenko.
(quote fixed by hand) On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote:
I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)?
Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to finalization. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project@lists.gforge.inria.fr; andres.valloud@gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may be right...
Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result. Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Tuesday, December 27, 2011 9:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: (quote fixed by hand) On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote:
I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)?
Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to finalization. Levente Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project@lists.gforge.inria.fr; andres.valloud@gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may be right...
Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
I don't know how to parse "weak set nilling is totally unrelated to finalization", maybe we're talking about different things when we use the term "finalization", I don't know. On 12/27/11 10:59 , Schwab,Wilhelm K wrote:
Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result.
Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Tuesday, December 27, 2011 9:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
(quote fixed by hand)
On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote:
I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)?
Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project@lists.gforge.inria.fr; andres.valloud@gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may be right...
Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote.
Levente
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any type of collection. It happens *to* elements that can be held in any type of weak collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold strong references to its elements, so they can be garbage collected when there are no other strong references to them. Finalization is a service which triggers an action when an object is garbage collected. Some finalization techniques require the use of weak collections, but otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves@elte.hu] Sent: Monday, December 26, 2011 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to understand than changed/update. I don't really care whether or not the latter is removed, because I never (directly) use it. Others might prefer to have it retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and finalization done *really* well. In fairness, my working image is old and I need to take another stab at building a recent image, but when I last reviewed them, Pharo's weak collections were lacking features. They have to be thread safe, and they need to clear nil entries left behind by finalization (which is why they must be thread safe). The better we get with events (#on:send:to and friends), the more the current weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The other weak collections are not subject to finalization, therefore they don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, December 26, 2011 10:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates. In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet is refreshed. So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self changed: #selectionIndex". I built a GUI that had two of them, and couldn't differentiate between the updates, so I was going to enhance it a little.
-- View this message in context: http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
.
participants (7)
-
Andres Valloud -
Igor Stasenko -
Levente Uzonyi -
Noury Bouraqadi -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse