apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: apr_threadkey
Date Sun, 29 Apr 2001 23:52:28 GMT

Makes sense to me.  +1 for removing it.

Ryan

On Sun, 29 Apr 2001, Doug MacEachern wrote:

> On Sun, 29 Apr 2001 rbb@covalent.net wrote:
>
> > On Sun, 29 Apr 2001, Doug MacEachern wrote:
> >
> > > wait a sec, i am blind.  apr_threadkey_private_{get,set} does what i
> > > expected.  its apr_threadkey_data_{get,set} that uses
> > > apr_pool_userdata_{get,set}.  this part of the api should probably be
> > > removed.
> >
> > Why would you remove that part of the API?  It is just as useful or
> > useless as the rest of the userdata_{get,set} functions, isn't it?  Maybe
> > not, because threadkey's are basically the same thing.  Whatever, no real
> > opinion here.
>
> apr_pool_userdata_{get,set} is very useful.
> apr_threadkey_private_{get,set} is very useful.
> the trouble here is when pool userdata is mixed with tls.
> as i said, you risk multiple threads writing to the same pool with no
> locking.
>
> look again at my example:
>
> static apr_threadkey_t *thr_key;
>
> static void hook_post_config(apr_pool_t *pconf, ...)
> {
>      apr_threadkey_private_create(&thr_key, NULL, pconf);
> }
>
> now elsewhere at request time we have:
>
> int foo_handler(request_rec *r)
> {
>     ...
>     apr_threadkey_data_set(&foo, "bar", thr_key);
>     ...
> }
>
> underneath calls:
> apr_pool_userdata_get(data, key, threadkey->cntxt);
>                                  ^^^^^^^^^^^^^^^^
> multiple threads cannot be writing to this pool at the same time.
>
>


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message