On Wed, Jul 18, 2001 at 08:18:25AM -0700, [EMAIL PROTECTED] 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
