Makes sense to me. +1 for removing it.
Ryan
On Sun, 29 Apr 2001, Doug MacEachern wrote:
> On Sun, 29 Apr 2001 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
