apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: Thread-specific data
Date Sun, 03 Mar 2002 15:13:22 GMT
Ryan Bloom wrote:
> 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                  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
>>
> 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