Re: Garbage collector issues

["Stefano Lanzavecchia" <stf@...>]

> Subject: Re: Garbage collector issues
>
> >There have been long threads on the .NET
> >maillist and newsgroups about deterministic finalization.
>
> Lua suports this by calling GC tag methods in reverse order of tags.
> --lhf

Er... yes and no. The problem is that you can force GC, but if you want
something more fine-grained so that small objects are GC'ed when required
whereas big objects or objects holding on to precious resources (database
connections) are GC'ed immediately (i.e.: when they "go out of scope") you
need some special method.

>    From: Nicolas Devillard <ndevilla@eso.org>
> Subject: Re: Garbage collector issues

> > Anyway, the one thing you can do is to provide two ways of
> > deallocation: one via GC, and one via a custom call which leaves the
> > userdata floating around but deallocates the large buffers.
> At GC time
> > you simply check if the buffers are still allocated or not.
>
> Yep, good point. But this requires more than one destructor
> for the same
> object, which might confuse the users of your C/C++ parts.

I was thinking something like (pseudolanguage):

class myClass {
	void *hugeBuffer;
	myClass() { hugeBuffer = malloc(BIGNUM); }

	~myClass() {
		if(hugeBuffer!=NULL)
			free(hugeBuffer);
	}

	dispose() {
		free(hugeBuffer);
		hugeBuffer=NULL;
	}
}

Now you can call dispose when you don't need the object any more and wait
for GC to make the userdata disappear. Or you can forget to call dispose and
wait for GC to call the destructor.

--
WildHeart'2k - mailto:stf@apl.it
Homepage: http://come.to/wildheart/

<<<Katte ni kimeru na yo! ---
   I didn't agree to this!>>>