2009/11/2 Yoshiki Ohshima <[email protected]>: > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
