You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Doug MacEachern <do...@covalent.net> on 2001/04/29 21:41:14 UTC
apr_threadkey
it looks like apr_threadkey_t cannot be used as tls is meant to be. for
example:
static apr_threadkey_t *thr_key;
static void hook_post_config(apr_pool_t *pconf, ...)
{
apr_threadkey_private_create(&thr_key, NULL, pconf);
}
it is not possible to use thr_key at request time because
apr_threadkey_private_{get,set} use apr_pool_userdata_{get,set}, rather
than pthread_{get,set}specific. so we have concurrent threads hitting the
same pool, rendering the apr_threadkey_private api useless.
i would have expected that apr_threadkey_create registers a cleanup to
delete the key and that apr_threadkey_private_{get,set} do not touch
the pool, but use pthread_{get,set}specific (or platform equivs)
is it just the case that the implementation has not been completed or just
an oversight or am i totally missing something?
Re: apr_threadkey
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: apr_threadkey
Posted by Doug MacEachern <do...@covalent.net>.
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.
Re: apr_threadkey
Posted by rb...@covalent.net.
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.
:-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: apr_threadkey
Posted by Doug MacEachern <do...@covalent.net>.
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.
Re: apr_threadkey
Posted by rb...@covalent.net.
> it is not possible to use thr_key at request time because
> apr_threadkey_private_{get,set} use apr_pool_userdata_{get,set}, rather
> than pthread_{get,set}specific. so we have concurrent threads hitting the
> same pool, rendering the apr_threadkey_private api useless.
> i would have expected that apr_threadkey_create registers a cleanup to
> delete the key and that apr_threadkey_private_{get,set} do not touch
> the pool, but use pthread_{get,set}specific (or platform equivs)
> is it just the case that the implementation has not been completed or just
> an oversight or am i totally missing something?
TLS was never really tested or finished. I think the general idea was
that it isn't really useful. Since every thread has its own pool in
Apache, we can just as easily use userdata that we provide. I believe we
should just remove the TLS code from APR personally, but I am perfectly
happy to be told why we shouldn't. I have no really strong feelings
either way. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------