apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <Marc.M.Adk...@Doorways.org>
Subject Thread-specific data
Date Sun, 03 Mar 2002 04:32:48 GMT
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


Mime
View raw message