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.