2009/11/2 Yoshiki Ohshima <yoshiki@vpri.org>:
At Mon, 2 Nov 2009 19:18:09 +0100, Lukas Renggli wrote:
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff.
Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution.
 Just to be clear.  Is it because the need to process the dictionary that registers the objects needs to be finalized, right?  For this case, these subscriptions objects don't have to be finalized, I think.  The subscriber holds onto a WeakArray of size one, and the element just becomes nil.  And when announcing something, you can just skip (and remove) subscription objects who have nil subscribers.
Yes.. i came to same conclusion and started implementing it, but then backstabbed with impossibility to make block-based subscriptions weak. :) Since we expect that eventually there will be a new announcement, we could wipe weak entries during this cycle. Keeping a garbage entries until new announcement will come don't seem to be a big problem.
 Or, is there actually a problem just having weak arrays?
No, i think the main issue is an overhead of squeak's finalization logic.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.