apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Threads and their Pools
Date Sat, 14 Jul 2001 11:01:00 GMT
>> 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.


View raw message