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.
