apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: apr_threadkey
Date Sun, 29 Apr 2001 23:43:54 GMT
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.


Mime
View raw message