chicken-users
[Top][All Lists]
Advanced

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

finalizers and stuff (Re: [Chicken-users] Cairo binding)


From: Hans Bulfone
Subject: finalizers and stuff (Re: [Chicken-users] Cairo binding)
Date: Tue, 11 Mar 2008 23:32:03 +0100
User-agent: Mutt/1.5.16 (2007-06-09)

hi,

On Tue, Mar 11, 2008 at 07:25:22PM +0000, Luke McCarthy wrote:

> A question for the list...
> 
> In the current Cairo egg resources like the cairo context must be 
> explicitly destroyed (with cairo-destroy). Do you think it's a good idea to 
> put these under control of the garbage collector by setting a finalizer to 
> automatically free the resources? Possibly we could leave both options 
> available, removing the finalizer if the resource is explicitly destroyed. We 
> could also have a macro like (with-cairo-context name surface . body)

i've asked myself the same question for the directfb egg i'm currently
working on.

i've decided to have two versions of every constructor
function, e.g. dfb-create-surface and dfb-create-surface*.
the * version creates the object without the finalizer, the other
version with finalizer.

dfbs-release (the function registered as finalizer) may be called multiple
times on the same surface, so it's ok to manually release a surface
created with dfb-create-surface.

(i have exposed the lower-level dfb-create-surface* like functions that
don't register a finalizer only because i think i've read somewhere that
having many objects with finalizers is slow so i wanted to make them
optional).

but i'm not sure if it was the right decision now... i've had some problems
with finalizers not being invoked before the program terminates (and directfb
complains when not all objects are released properly).  i wonder if it's ok
to depend on finalizers being called before the program terminates.  also, it
seemed to not work at all with csi, only when all code is compiled.

in my case, the finalization problems go away when i do a
(thread-sleep! 0.001) somewhere near the end, i think because a continuation
with a reference to some directfb objects is still stored in the thread
from a previous thread-sleep! call but i haven't checked thoroughly.

but this has made me think that it might be better to make memory management
for those resources more explicit, like with those with-xxx style macros
you mentioned... otoh you might not always want to have resource creation
and destruction in the same function...

> Another question - how do you remove a finalizer? I suppose
>   (set-finalizer! obj (lambda (x) (void)))
> might work, assuming it overrides the old one. Is there a better
>   way?

this doesn't work (at least not with chicken 2.732 where i tested it).
the old finalizer isn't overwritten, both are called when the object
is garbage collected.

bye,
hans.




reply via email to

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