httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: async not./canc. (was Re: First in a long line of APR related patches.)
Date Wed, 25 Aug 1999 23:49:41 GMT
On Wed, Aug 25, 1999 at 04:01:58PM -0700, Dean Gaudet wrote:
> I've pointed out that pools aren't as useful in a threaded environment... 

Why not? I'm curious. Because the per-thread pools can't share their
free memory?

> and I think we'll find that having them in every APR function is going to
> weigh things down even more.

Some of the APR functions will need memory (and yeah, this should be
minimized, but I don't think it can be avoided). I can think of 4 ways
to give APR this memory

1. give it pools to allocate it from
2. let it use malloc/free (what NSPR does)
3. give APR function pointers to a custom malloc/free
4. require the caller to preallocate all APR structures before the APR
   calls are made

I'm happiest with 1 or 4, but I'd think all of them would cause equal
amounts of added weight. What do you have in mind?

> Pools are also less useful when there is no async cancellation...

Maybe, but they still are really nice because they essentially give us
the semantics of a garbage-collection-based language, meaning we don't
have to worry about annoying problems like who owns which blocks of
memory. They made my reentry into C from JavaLand much more pleasant.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Violence is the first refuge of the violent." - Aaron Allston

Mime
View raw message