Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector

[Peter Bex]

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