On Wed, 18 Jul 2001, Justin Erenkrantz wrote: > 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. =)
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 _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
