At 6:52 PM -0500 4/3/02, Bryan C. Warnock wrote:
>On Wednesday 03 April 2002 16:55, Michel J Lambert wrote:
>> > Why add new functions instead of patching the current ones?
>>
>> I didn't know if the original functions still had a purpose. Perhaps you
>> would want to Parrot_allocate for something non-bufferish? Thinking about
>> it, that seems evilly wrong, so I guess that is not a valid reason. Doing
>> this would make mem_realloc and Parrot_reallocate_buffer a little bit more
>> difficult, since they'd have to allocate a temporary buffer on the stack
>> to call the function, or stash away the values of the incoming buffer
>> before it gets overwritten, so it can later memcpy.
>>
>> Should I resubmit a patch removing the _buffer suffix, and removing
>> mem_realloc?
>
>The concern is that both functions are still using the same arenas, which
>means the original problems still wouldn't be solved, and we'd still have to
>do all the workarounds around them. ;-)
That should be OK. Calling Parrot_reallocate in the middle of a GC
run will take the new memory from the new pools, since the GC
switches pool pointers at the start of its compaction phase.
I'm going to go in and make Parrot_reallocate take Buffers, which is
what it should've done in the first place. Parrot_allocate too.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
