I think you should really look at just putting this information in the hash that is stored in a pool. All threads and all processes should have their own pools for maximum allocation performance, so you should have the pool to store data in, the only question is if you will have the pool in the correct functions.
the problem (for me at least) is sometimes you don't know what your pool pointer is, and what your storing is the actual pool pointer itself
a example for this is when we replace Berkley DB's default allocator with a pool based one (needed to make a thread-safe DBM call)
I hope that helps, let me know if you have any more questions.
Ryan
----------------------------------------------
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
-----Original Message----- From: Marc M. Adkins [mailto:[EMAIL PROTECTED] Sent: Saturday, March 02, 2002 8:33 PM To: [email protected] Subject: Thread-specific data
OK...here goes...
My goal is to have a function within a module reference a
thread-specific
data item. I want the state of the data item to be settable and
gettable
over time, but different for each thread. I don't want to pass an apr_thread_t object in and out of the function, in fact it has to work
the
same for single-threaded code where there are no thread objects
created at
all.
I've been staring at the thread/proc stuff for awhile. I think I'm
seeing
four different families of functions that relate to "thread-specific" data:
apr_thread_attr_ apr_thread_data_ apr_threadkey_private_ apr_threadkey_data_
The _private_ calls directly relate to thread-specific indices created
by
the operating system. These seem to automatically sense what thread you're in (important to the code I want to write). They don't have cleanup
calls
like the second and fourth families.
The first, second, and fourth families seem to use userdata calls associated with pools. [It's interesting that the pools have optional hashes associated with them, I'm sure there's a reason for this...]
I'm confused about what the different function families are for...but
I
don't actually have to know just now. What I need is to set up a data item on each thread at need.
I'm thinking that _if_ I had a function like apr_current_thread() I
could
use the first or second function families (but what is the difference between the two?). I could also use the third one to generate a
memory
space and then switch to the fourth one with the apr_threadkey_t thus created and use the cleanup function. Or something like that. But
then I
need a place to put the apr_threadkey_t item...associated with the
current
thread, of course. So I'm kind of back to square one.
I think that I can dummy up apr_current_thread using
apr_os_thread_current
and apr_os_thread_put, but I'm not convinced that I would get the
"same"
apr_thread_t object each time. Which is (I think) what I want.
I think I just don't have the right perspective on the problem. Y'all probably planned for this somehow and I'm just not in the loop, so
I've
missed the obvious answer.
I looked briefly in the 2.0 codebase and didn't find any examples.
Marc M. Adkins
