On Fri, Jul 17, 2015 at 04:03:30PM +0000, Mathieu Desnoyers wrote:
> ----- On Jul 17, 2015, at 6:58 AM, Ondřej Bílka [email protected] wrote:
> [...]
> >> If we invoke this per-thread registration directly in the glibc NPTL
> >> implementation,
> >> in start_thread, do you think it would fit your requirements ?
> >>
> > A generic solution would be adding eager initialization of thread_local
> > variables which would fix more performance problems.
>
> Concretely, what code would be in charge of this initialization ?
>
> What changes does "eager initialization" imply from the current
> implementation ?
>
Now if you write
class foo{
public:
foo(){
printf("init\n");
}
foo(const foo &x){
printf("init\n");
}
int bar()
{
return 32;
}
};
thread_local class foo x;
Then constructor isn't called in all threads, only main as its lazily
initialized. You need to call x.bar() in each thread to cause
initialization.
> > Second would be write patch to libc adding function
> > pthread_create_add_hook_np to register function that would be ran after
> > each thread creation.
>
> Do you suggest that this callback should be registered once per thread,
> or somehow attached to pthread_attr_t ? As maintainer of lttng-ust,
> where we need some control over our own threads, but where we want minimal
> impact on the overall application, I would really prefer if we can attach
> the callback to pthread_attr_t.
>
Could you elaborate. I was suggesting per-thread callback, what do you
want to do with pthread_attr_t?
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
