apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [PATCH] Fix apr_thread_exit(), change apr_thread_start_t, etc...
Date Wed, 18 Jul 2001 15:33:27 GMT
On Wed, 18 Jul 2001, Justin Erenkrantz wrote:

> On Wed, Jul 18, 2001 at 08:18:25AM -0700, rbb@covalent.net wrote:
> > IMNSHO, this is wrong for two reasons.  #1, if the app has access to the
> > apr_thread_t, then they also have access to the pool.  We have a macro
> > called APR_POOL_IMPLEMENT_ACCESSOR that specifically creates accessor
> > functions for the pools.  Threads may not implement that function yet, but
> > it is far better to allow one method for accessing the pool.  #2, why are
> > we passing the apr_thread_t as a separate parameter to the thread?  That
> > is introducing a layer of indirection that isn't required here.  Just
> > create an apr_thread_param_t structure that is:
> I believe that we don't have access to the pool in apr_thread_t.  This
> is a private structure that is defined per architecture.  If there is a
> way of accessing the pools in the apr_thread_t portably, I'd like to
> know where it is.  The obvious thing to do is look in the struct, but we
> can't do that.  Please enlighten us by showing us where in the code to
> do this.  =)

Re-read my message please.  We have a macro APR_POOL_IMPLEMENT_ACCESSOR,
which will create a function that gives you access to the pool from ANY
apr type.  Just grep the APR code to determine how to use it.

> As for passing the apr_thread_t in, we need it for apr_thread_exit for
> reasons described earlier.  For example, in the threaded MPM, the
> apr_thread_t** exists only on the stack not in static space.  I think it
> would be cleaner if we passed it in to the worker function rather than
> relying on it being in a global scope.

Again, re-read my message.  I didn't say don't pass it to the thread
function.  I said don't do it the way your patch implements it.


Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message