On Tue, Jun 19, 2012 at 10:38:43AM -0400, John Cowan wrote: > Felix scripsit: > > > This means the number of finalizers is limited to (currently) 4096. Code > > that produces many finalizers must make sure they are triggered (and > > thus un-registered) fast enough. > > Ick, ick, ick. This is a horrible solution. The main use of finalizers > that I've ever had is when dealing with objects allocated by C libraries; > a pointer object wrapped in a finalizer insures that when the foreign > object is no longer interesting to the Scheme side, it is properly freed, > which may or may not involve calling free().
I completely agree here. This patch will make things worse. Instead of hurrying for a release and making incomplete/incorrect patches I think it's better to fix the bugs we have first. > Why does there have to a be a persistent array of all finalizers anyway? > The garbage collector itself can find them during the mark phase. The GC needs to be able to associate an object with its finalizers, so there either needs to be a global list or some extra slot added to each object. The latter takes up more memory when you don't have a lot of finalizers (and finalizers are slow, so it's best not to generate too many of them). What I don't quite understand is all this talk about threads. The test program doesn't even create any extra threads, so how could there be any race conditions? There shouldn't *be* any concurrency in this case, should there? Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
