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.
