apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Thread-specific data
Date Sun, 03 Mar 2002 04:45:25 GMT

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

> 	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 Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Marc M. Adkins [mailto:Marc.M.Adkins@Doorways.org]
> Sent: Saturday, March 02, 2002 8:33 PM
> To: dev@apr.apache.org
> Subject: Thread-specific data
> OK...here goes...
> My goal is to have a function within a module reference a
> data item.  I want the state of the data item to be settable and
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> thread, of course.  So I'm kind of back to square one.
> I think that I can dummy up apr_current_thread using
> and apr_os_thread_put, but I'm not convinced that I would get the
> 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
> missed the obvious answer.
> I looked briefly in the 2.0 codebase and didn't find any examples.
> Marc M. Adkins

View raw message