apr pools with threads

[Stephen Ciscola <cr...@yahoo.com>]

Hi,

I want to use a pool or pools to replace some malloc
calls in a library i'm working with. I want to avoid
the constant malloc/free penalty. I intend to just
toss some defines in to call the pools api whenever
malloc/free is called.

My application is multithreaded. Am I correct that if
I use pools with an APR I built on linux using 
-enable-threads, that they AREN'T inherently thread
safe?

I still need to mutex lock around.... ??? which pool
calls?

I assume it's fine if I use normal pthread calls, not
the APR threads model... though I'm free to use either
really.

thank you. I found a few messages about this here re.
pools and inherent thread safety, but would like to
confirm my understanding is correct.

thank you!
Stephen

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: apr pools with threads

[Nick Kew <ni...@webthing.com>]

On Tuesday 03 October 2006 13:07, Stephen Ciscola wrote:
> Hi,
>
> I want to use a pool or pools to replace some malloc
> calls in a library i'm working with. I want to avoid
> the constant malloc/free penalty. I intend to just
> toss some defines in to call the pools api whenever
> malloc/free is called.

A good strategy if your pool is (or can be) tied to the natural
lifetime of the resources you're allocating.

> My application is multithreaded. Am I correct that if
> I use pools with an APR I built on linux using
> -enable-threads, that they AREN'T inherently thread
> safe?

Yep.

> I still need to mutex lock around.... ??? which pool
> calls?

If your pool is shared across threads, yes.  But that would be
an inefficient usage, and could potentially require the vast
majority of APR calls to be mutexed.  Can't you create a
private subpool per thread instead?

> I assume it's fine if I use normal pthread calls, not
> the APR threads model... though I'm free to use either
> really.

I suspect you'll risk losing portability by doing that.

-- 
Nick Kew