Okay, this is relatively easy to explain, if you really understand the thread functions. You are on the right track, and I will do my best to answer your question.
First, the four data types, slightly re-arragned: > apr_thread_attr_ This is a place to store attributes about a thread. This structure should be used to help create a thread and is almost definitely not what you want. In general, the APR code uses this structure, and nobody else really should add anything to it. > apr_threadkey_private_ This is essentially thread-local storage, and the API should be directly analogous to pthread_key_* functions. Use man pthread_key_create to learn more about this set of functions. The whole point of this is to allow a thread to put information in a place that no other thread can get to. This may or may not work in a non-threaded app, I haven't tried. > apr_threadkey_data_ > apr_thread_data_ Both of these are essentially identical. They are ways to store data in the pool that is stored in either the apr_threadkey_t and apr_thread_t structures. In order to use either of these function sets, you must have an instance of the base type, either thread or threadkey. If you are writing a non-threaded app, then using the apr_thread_data functions is probably not good, and the apr_threadkey_data functions are pretty much redundant, because it doesn't add anything that the base class can't do. 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. 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
