[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: rb_raise and memory

George Ogata

3/10/2005 5:48:00 PM

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

> Hi,
>
> In message "Re: rb_raise and memory"
> on Thu, 10 Mar 2005 08:25:49 +0900, Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:
>
> |No problem. Is there a simple workaround (other than explicitly
> |calling free before rb_raise), such as registering the address with the
> |GC? One would have to wrap it in a VALUE it seems, which isn't
> |great...
>
> There's no way for Ruby GC to handle non-VALUE data. The only
> solution I can think of is moving to Boehm GC, which might be an
> overkill.
>
> matz.

Won't ALLOCA_N work for this, or am I not following?
4 Answers

Garrett Rooney

3/10/2005 5:51:00 PM

0

George Ogata wrote:
> Yukihiro Matsumoto <matz@ruby-lang.org> writes:
>
>
>>Hi,
>>
>>In message "Re: rb_raise and memory"
>> on Thu, 10 Mar 2005 08:25:49 +0900, Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:
>>
>>|No problem. Is there a simple workaround (other than explicitly
>>|calling free before rb_raise), such as registering the address with the
>>|GC? One would have to wrap it in a VALUE it seems, which isn't
>>|great...
>>
>>There's no way for Ruby GC to handle non-VALUE data. The only
>>solution I can think of is moving to Boehm GC, which might be an
>>overkill.
>>
>> matz.
>
>
> Won't ALLOCA_N work for this, or am I not following?

alloca memory is deallocated at the end of the scope, which is not a
good thing if you expect to use it later...

-garrett

George Ogata

3/10/2005 6:08:00 PM

0

Garrett Rooney <rooneg@electricjellyfish.net> writes:

> alloca memory is deallocated at the end of the scope, which is not a
> good thing if you expect to use it later...

Right, I was thinking of a different situation. Sorry.

Charles Mills

3/10/2005 7:32:00 PM

0


George Ogata wrote:
> Yukihiro Matsumoto <matz@ruby-lang.org> writes:
>
> > Hi,
> >
> > In message "Re: rb_raise and memory"
> > on Thu, 10 Mar 2005 08:25:49 +0900, Nikolai Weibull
<mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:
> >
> > |No problem. Is there a simple workaround (other than explicitly
> > |calling free before rb_raise), such as registering the address
with the
> > |GC? One would have to wrap it in a VALUE it seems, which isn't
> > |great...
> >
> > There's no way for Ruby GC to handle non-VALUE data. The only
> > solution I can think of is moving to Boehm GC, which might be an
> > overkill.
> >
> > matz.
>
> Won't ALLOCA_N work for this, or am I not following?

ALLOCA_N allocates memory on the stack. ALLOC, ALLOC_N and friends
allocate memory in the heap. (you probably alreay know this)
Anyway, I think Matz is saying that it is possible to use a GC which
tracks all memory allocated from the heap (not just Ruby objects).
Personally I like the way it is currently done. It makes it easy to
use existing libraries which use alloc/free.

-Charlie

ES

3/10/2005 8:24:00 PM

0

On Thu, March 10, 2005 5:51 pm, Garrett Rooney said:
> George Ogata wrote:
>> Yukihiro Matsumoto <matz@ruby-lang.org> writes:
>>
>>
>>>Hi,
>>>
>>>In message "Re: rb_raise and memory"
>>> on Thu, 10 Mar 2005 08:25:49 +0900, Nikolai Weibull
>>> <mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:
>>>
>>>|No problem. Is there a simple workaround (other than explicitly
>>>|calling free before rb_raise), such as registering the address with the
>>>|GC? One would have to wrap it in a VALUE it seems, which isn't
>>>|great...
>>>
>>>There's no way for Ruby GC to handle non-VALUE data. The only
>>>solution I can think of is moving to Boehm GC, which might be an
>>>overkill.
>>>
>>> matz.
>>
>>
>> Won't ALLOCA_N work for this, or am I not following?
>
> alloca memory is deallocated at the end of the scope, which is not a
> good thing if you expect to use it later...

Well, there's an argument to be made that any memory that's to be used
later should be either invalidated by the exception or released somewhere
else anyway.

> -garrett

E