From: Peter Hickman <peter@...>
Date: 2002-07-03T23:17:44+09:00
Subject: Re: Ruby implementation Q's

Justin Johnson wrote:

>>Programmers have spent a great deal of time trying to avoid presisly
>>this sort of problem so I am at a loss as to why you think this would be
>>useful in anyway.
>>
>
>Ok, imagine I have a class that represents bitmap resources, 3d geometric
>models or sounds.  These are resources that are allocated externally to Ruby
>and are not garbage collected.  Imagine I have written a C/C++ extension to
>allow Ruby to request/release such external resources.
>
>Perhaps I have a var referencing the resource: myvar = bitmap("image.tga").
>Now, when myvar becomes unreferenced, I still have the bitmap image taking
>up memory.  This will be the case until garbage collection, whereby
>finalization can be done and I can release my external bitmap image.  My
>memory may therefore become full with unused resources that are waiting for
>garbage collection to finalize and release them.
>
>The problem becomes worse if the resources are allocated via a limited
>number of handles.  Such as file handles.
>
>The ideal would be for finalization to happen as soon an object becomes
>unreferenced although I can't think of a 100% sure way of achieving that.
>
>--
>Justin Johnson
>justinj@mobiusent.com
>Technical Director
>Mobius
>
>
>
>

How about a class with the following interface.

x = BitMapLoader.new();

x.loadbitmap("image.tga");
x.dosomethingwiththedata();
x.unloadbitmap();

The unloadbitmap method would, back in the C code, unallocate the memory 
used by data and therefore free up the resources. However the referent x 
still has currency with a much smaller footprint and can be GCd later.

I will admit that I do not have any experiance with the Ruby to C 
interface but if you can allocate memory from within the C interface 
then you should be able to unallocate it.

If you can't do this then I can see your problem is somewhat greater 
than I have assumed.