[Firebird-test] Re: [Firebird-devel] Running TCS against FB1.5Alpha2

[John B. <bel...@cs...>]

Claudio,

On Saturday, October 12, 2002, at 05:57 PM, Claudio Valderrama C. wrote:

>> -----Original Message-----
>> From: fir...@li...
>> [mailto:fir...@li...]On Behalf Of John
>> Bellardo
>> Sent: Viernes 11 de Octubre de 2002 11:26
>>
>>>> You MUST allocate all memory from a pool.  Don't use the default
>>>> global new().
>>>> [...]
>>
>> The original intent for that message turned out to be too aggressive.
>> That functionality should just be dropped.  It is ~5 lines in two
>> places in the file src/common/memory/allocators.cpp.  Search for
>> "printf" and you should be able to find it.
>
> Can you explain more? Are you saying that it doesn't matter whether 
> memory
> comes from the allocator or comes directly from the heap used by the 
> "new"
> operator? I thought all memory inside the engine would be managed by 
> the
> allocators.

I'm not saying it doesn't matter.  It does matter for a number of 
reasons.  The most important being that we must define our own global 
operator delete to handle internal structures that don't/can't (still C 
structs) provide one.  This means we trap _all_ calls to delete, 
including those that are deleting memory from the global new.  We don't 
have a way to distinguish between those memory allocations, and as a 
result all allocations must go through our pools/allocators. I'm saying 
that the enforcement mechanism that produced that error message is 
sub-optimal.

> But if some implementations use the original new operator, probably it
> happens inside units where our changed operator isn't visible. Is this 
> the
> problem?

Yes, that is correct.  I've only seen it happen in some STL 
implementations though, and only for a very small amount of memory.  
Hence the "grace period" before the error message.

-John