Head vs 0.9.7

[Ron Ohmer <ro...@aisconsulting.net>]

I am working with the latest CVS build...
 
I am running into issues with Pools.  Which are now required for different adapters..
 
In our EventLogger instance, I am trying to create a pool...
 
My code is:
 
_logPool=new log4cxx::helpers::Pool();

where _logPool is defined as:
log4cxx::helpers::Pool *_logPool;

 

But that is no cutting it.

are there any examples (New examples that use pools)?  I am not finding any...


Thanks!

Ron

---------------------------------------------------------------------- 
Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837	

Re: Head vs 0.9.7

[Curt Arnold <ca...@apache.org>]

Ron Ohmer wrote:

>I am working with the latest CVS build...
> 
>I am running into issues with Pools.  Which are now required for different adapters..
> 
>In our EventLogger instance, I am trying to create a pool...
> 
>My code is:
> 
>_logPool=new log4cxx::helpers::Pool();
>
>where _logPool is defined as:
>log4cxx::helpers::Pool *_logPool;
>
> 
>
>But that is no cutting it.
>
>are there any examples (New examples that use pools)?  I am not finding any...
>
>
>Thanks!
>
>Ron
>
>---------------------------------------------------------------------- 
>Startuj z INTERIA.PL!!! >>> http://link.interia.pl/f1837	
>  
>
I'm curious why you think you need to create one. 

Pools are internal detail, hopefully most users will never need to know 
that they exist.

Methods in Apache Portable Runtime (APR) take an apr_pool_t* parameter 
when they might allocate memory to perform the function.  Since 
dispatching a logging event might call APR methods that might allocate 
memory, a log4cxx::Pool instance is allocated on the stack before 
dispatching the event and passed down to the appenders.  At then end of 
the dispatch, the log4cxx::Pool is destructed which will cause all 
memory allocated from the pool to go out of scope.

log4cxx::Pool& was used in the method signature instead of apr_pool_t* 
to avoid requiring log4cxx using applications to have to have APR 
include files in their include path.  The apr_pool_t* within a 
log4cxx::Pool can be retrived using getAPRPool().

There are two patterns in Pool use within log4cxx. 

Some log4cxx objects need to create a long-lived APR objects, like a 
file, socket, mutex, etc.  Since the APR objects are reclaimed when 
their pool is destroyed, the pool must live at least as long as the file 
or socket.  In these cases, the Appender (or other log4cxx instance) 
will contain a Pool member variable that is used to allocate resources 
that have comparable lifetimes to the log4cxx object.  So you'd have 
something like:

class MyWidget {
    private:
    log4cxx::helpers::Pool p;
};

The other use of pools are for transient objects or memory blocks.  The 
Pool in StringHelper::toString(int, Pool&) is there since apr_itoa takes 
a apr_pool_t* parameter.  The intent is that most of these calls occur 
during event dispatching and the Pool& passed into the appender in 
doAppend() is used for these allocations  If you need to create a 
short-lived pool for a short-lived allocation, you would do something like:

Pool p;
std::wstring dst;
StringHelper::toString(i, dst, p);