apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: Threads and their Pools
Date Sat, 14 Jul 2001 01:07:54 GMT
On Fri, Jul 13, 2001 at 04:33:51PM -0700, Justin Erenkrantz wrote:
> On Fri, Jul 13, 2001 at 07:20:26PM -0400, Cliff Woolley wrote:
> > Semi-related to this is something I was wondering about this morning when
> > I woke up, which is this: what happens if there's a per-thread allocator
> > (sms) that's used as the parent of all sms's in that thread, and some
> > portion of the code (maybe a module) running in that thread decides to
> > spawn off some child threads?  Clearly it cannot use the per-thread sms as
> > the parent sms for the pools created in the child threads.  Should it
> > start over with an apr_sms_std as the parent sms for all sms's in the
> > child thread?
> Which is why Sander and I were tossing the idea of creating that in the
> apr_thread_create function.  Ideally, the apr_thread_create function
> would create a threads/trivial SMS parented by the global pool (std -
> which is malloc-based) for each thread.
> (Aaron prolly hates this idea.  Actually, he's sitting behind me yelling
> at me for writing this...)
> Now, I'm not sure how realistic this is, but that's my initial thought.
> -- justin

I suppose I have to reply now... *grin*

Instead of referencing the global pool (And breaking all the rules
of your first CS course where they said "don't use global variables")
all the time, why don't we allow whatever called "apr_thread_create" to
pass in the pool that the thread is to use directly, instead of passing
it one it is supposed to use as a parent.

Isn't the whole point of passing in an allocator resource (the apr_pool_t *pool
argument) to all the APR functions merely so that the *caller* of
our various APR functions can completely control the scope of the data
that is allocated during that call? When I call apr_pstrdup() with a pool,
I want that pool to define the lifetime of that memory, I don't want it to
allocate memory that goes out of scope at un undefined time before or
after apr_pstrdup() returns...


View raw message