apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Fix apr_thread_exit(), change apr_thread_start_t, etc...
Date Wed, 18 Jul 2001 15:28:21 GMT
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.  =)

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.

> Now, we can re-define the APR_THREAD_FUNC api to be
> +typedef void *(APR_THREAD_FUNC *apr_thread_start_t)(apr_thread_param_t *);

Fine.  I don't care much, but I think the other way is a tad more
explicit/clearer about what to do.  It all depends on where the
marshaling/unmarshaling happens.  It achieves the same result, IMHO.
-- justin

View raw message