>> APR threads should be allocating a sub-pool on all platforms. > > This is where I disagree, but only slightly: > > APR threads should be *using* a sub-pool on all platforms. I believe it > should be the responsibility of the caller to define the lifetime > of that thread and it's data, not the thread itself.
[...] > I still think the subpool could be created outside of apr_thread_create, > and passed in. This works well with the new SMS code, so threads that > are created for specific purposes could be paired up with a particular > SMS. Well, actually it is much more convenient to create a subpool/sms in apr_thread_create. This is because there is some administration that needs to be done to get the dynamic locking going. The thread an sms is created in, is the first thread registered. Once a second thread is registered, the locking is activated, because then there are two threads registered with that sms. So, the subpool/sms should be created _in_ the new thread and the thread should register with the sms passed into apr_thread_create. That way, all the memory management within the thread can be virtually without locking. Oh, and ofcourse, the thread needs to be unregistered at exit. This could be through cleanup, or by the method described earlier on list. [...] > But why must threads be involved in subpool creation? Threads do have a > lifetime, and therefore it makes sense to pass them a pool for > that purpose, but I don't see how threads need to be dictating other > pools. Well, the lifetime isn't any longer than the pool that is passed in, is it? So, either way, the lifetime is dictated by the pool passed in, be it the parent pool or a new subpool thereof. Sander
