Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 13 Jul 2001 19:20:26 -0400 (EDT)
From: Cliff Woolley <cliffwoolley@yahoo.com>
To: <dev@apr.apache.org>
Subject: Re: Threads and their Pools
In-Reply-To: <20010713161330.G20591@ebuilt.com>
Message-ID: <Pine.GSO.4.32.0107131917260.23175-100000@cobra.cs.Virginia.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 13 Jul 2001, Aaron Bannert wrote:

> 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?

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA