[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] Small fix to stabilize behavior

From: Felix
Subject: Re: [Chicken-hackers] [PATCH] Small fix to stabilize behavior
Date: Sat, 23 Jun 2012 22:47:36 +0200 (CEST)

> On Sat, Jun 23, 2012 at 02:53:21PM +0200, Peter Bex wrote:
>> > User programs can override the finalizer limit using the "-:f" runtime
>> > option if a large number of finalizations are expected or required in 
>> > specific applications.
>> I'd like a little more time to investigate the bug.  This patch can
>> always be applied.  It would be a shame if we can come up with a better
>> fix after this makes it into the release.
> Here's a patch that made one test function correctly.  The test is my
> own simplified version of Megane's test:
> (let lp ((x (list 1 2 3)))
>   (set-finalizer! x (lambda _ #f))
>     (lp (list 1 2 3)))
> This test used to fail with something like this:
> Warning: in finalizer: call of non-procedure: #<unspecified>
>         Call history:
>         /tmp/test.scm:3: lp       
>         /tmp/test.scm:2: set-finalizer!   
>         [...]
> [panic] out of memory - heap full while resizing - execution terminated
> After applying the patch, it just loops endlessly (which is the correct,
> expected behavior) without any errors.

Pushed. Definitely a bug - well done, Peter.  (I forgot to sign off
and I'm too stupid to figure out how to amend the patch below the
HEAD ...)

> Originally I overlooked it because (fx+ (fx* 2 _max_pending_finalizers) 1)
> looks like it can hold one more finalizer than _max_pending_finalizers,
> but then I figured that the vector is twice the size of
> _max_pending_finalizers because it holds pairs of values and their
> associated finalizer procedure.  The +1 is for the extra slot that keeps
> track of the number of finalizers.
> Question: Why the duplication with live_finalizer_count?  Are these
> two values subtly different somehow?

The "live-finalizer-count" is the number of finalizers registered, the
value in the first slot of ##sys#pending-finalizers is the number of
finalizers triggered and pending for execution. These counter should
be independent of each other, but since we have to be able to catch
the situation where all live finalizers become pending at once, the
length of ##sys#pending-finalizers must be >= the live finalizer
count. I think.


reply via email to

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