[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dyn

From: Christian Kellermann
Subject: Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector
Date: Wed, 20 Jun 2012 09:54:00 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Felix!

* felix winkelmann <address@hidden> [120619 11:38]:
> The attached patch adds exception handling around the invocation of
> finalizers, which are shown as warnings (unless warnings are disabled)
> but do not otherwise trigger errors (similar to the way errors in
> separate threads are handled). I still experienced random crashes when
> running the stress test in #866. What helped was removing the dynamic
> resizing of the vector stored in ##sys#pending-finalizers.  I could
> not found a decent explanation for this but having a vector of fixed
> size made the crashes go away. I assume there is some race-condition
> between code that runs pending finalizers and code that creates new
> ones ("set-finalizer!"). 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.
> Note that the "-:f" runtime option can be used to change the number of
> available finalizers.

Thank you for this patch! I don't want to add to the discussion of how
to do this Right(tm), since this probably just means making design
decisions according to design goals and people arguing whether their
design goal is better than the other's...

What I want to do instead is to propose the split of the two things
the patch does into two separate patches.  The fix for #866 is a good
one and I think that should go in. Then we can quarrel about the way
finalizers should be handled until either everyone gives up or maybe
we think of something else and provide a "better" patch based on a
common understanding of the problem.

Also I do think that it will not hurt the commit log when your
explanation is part of it. Sometimes I think of it when reviewing and
add it, most of the time its buried in the archives. I also know that
sometimes the time difference between making the patch and sending it
off to the list with the explanation may improve the latter ;)

So writing correct software is hard, drinks anyone?

Kind regards,


9 out of 10 voices in my head say, that I am crazy,
one is humming.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]