Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 13 Jul 2001 18:18:15 -0700
From: Aaron Bannert <aaron@ebuilt.com>
To: dev@apr.apache.org
Subject: Re: Threads and their Pools
Message-ID: <20010713181815.L20591@ebuilt.com>
References: <20010713161330.G20591@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010713161330.G20591@ebuilt.com>;
 from aaron@ebuilt.com on Fri, Jul 13, 2001 at 04:13:30PM -0700


Just for a little insight, this was promted while trying to sort through
the apr_thread_* API for use in "flood", the httpd-tester Justin and I
have been working on.

I was curious why apr_thread_exit() needed the apr_thread_t that it is
supposed to exit, since that is not typically something a thread has
direct access to. Then I realized that it was simply destroying the
pool that is a part of that apr_thread_t structure, and I became
suspicious.


I still don't see how a thread can call apr_thread_exit() for itself,
and I don't see any examples anywhere in httpd-2.0 or apr[-util].

-aaron


On Fri, Jul 13, 2001 at 04:13:30PM -0700, 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?
> 
> -aaron