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

[Felix]

>> 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.

Nobody is hurrying. The patch is also not incorrect - it is a
simplification and removes a potential problem.

> 
>> 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).

Exactly. Finalizers are junk. Finalizers are the last resort. Creating
excessively many of them is a design error. 

(That was just for the record)

> 
> 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?

There is concurrency between the garbage collector (that can kick in
at *any* moment) and library code. The GC has a linked list of
finalizers, allocated dynamically and theoretically unlimited in size
(and also nicely slowing down every major GC when you have lots of
them). But once finalizers are "triggered", they have to be stashed
somewhere. That somewhere is the "pending finalizers vector"
(##sys#pending-finalizers, IIRC) and that currently grows on demand.
I _assume_ (I don't know for sure), that there is some sort of problem
in the situation when ##sys#pending-finalizers must grow, and at the
same time is used by GC runtime system code to hold triggered
finalizers. It's all terribly complicated. And it's an absolute PAIN
to debug. We can probably figure out some funky clever solution for
this, something we can be really proud of. On the other hand, we can
just try to simplify things a bit, have a good old decent fixed size
buffer (out fathers weren't ashamed of them good old decent fixed size
buffers, right?), and tell those that put finalizers onto everything
to grow up.


cheers,
felix