apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: Threads and their Pools
Date Fri, 13 Jul 2001 23:26:18 GMT
> > It appears to me that APR threads (on unix) are automatically creating a
> > subpool, and then later destroying it only if/when apr_thread_exit() is
> > explicitly called. I have a few questions about
threadproc/unix/thread.c:
> >
> > 1) How do we guarantee the child-pool is being destroyed? What happens
> >   if the thread just exits?
> >   (I don't see anywhere in httpd that is calling apr_thread_exit().)
> >
> > 2) Why are we forcing applications using APR's threads to use pools
> >   in the first place? Even if we require some sort of allocator to get
> >   memory from for the thread structures themselves, why are we forcing
> >   them to be child-pools?
>
> 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?

Hmm, good question.  Maybe it could use the sms's parent?  Although that
would depend on what the parent was whether that was clever. This is
something else that needs looking into...

BTW, what in hells name were you doing thinking about this as you woke up???
:)

david



Mime
View raw message