>>> Fair enough. It's just that in order to opt-out of the >>> child-pool creating >>> process in apr_thread_create, we're going to have to add a parameter >> >> Why are we so desperate in opting out the child-pool creation? >> I don't really have problems with a child pool for each thread. >> Actually, it will make the dynamic locking a lot easier to implement >> if it stays. > > The problem is that apr_thread_create is completely bogus right now. > > The child thread has no access to that pool in apr_thread_t->pool. > If you want a pool in the thread, you should be creating inside > of the thread's function not in apr_thread_create.
I can live with that. It's the registration of the thread with the parent sms [when/if pools==sms] that has my interest :) > And, apr_thread_exit call should *not* be taking in an apr_thread_t > because the child doesn't have access to that either. Can't we pass in a data structure to the thread function which has all the required information? The data the user wants to pass in will need to be in the data structure aswell ofcourse. > We're enforcing the use of global variables to work around this and > that's plain wrong. -- justin Yes, I agree. Sander
