tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TLS support, MI part
On Fri, Mar 18, 2011 at 03:57:44PM +0000, Andrew Doran wrote:
> On Wed, Mar 09, 2011 at 12:35:04AM +0100, Joerg Sonnenberger wrote:
>
> > @@ -305,10 +314,16 @@
> >
> > static void
> > pthread__scrubthread(pthread_t t, char *name, int flags)
> > {
> >
> > +#if defined(__HAVE_TLS_VARIANT_I) || defined(__HAVE_TLS_VARIANT_II)
> > + if (t->pt_tls) {
> > + _rtld_tls_free(t->pt_tls);
> > + t->pt_tls = NULL;
> > + }
> > +#endif
>
> Is there any way it can be recycled efficiently? Since it will have an
> impact on threading benchmarks.
Not yet. I'm not sure how much can be gained from that since they have
to be initialised anyway.
> > struct __pthread_st {
> > pthread_t pt_self; /* Must be first. */
> > +#if defined(__HAVE_TLS_VARIANT_I) || defined(__HAVE_TLS_VARIANT_II)
> > + struct tls_tcb *pt_tls; /* Thread Local Storage area */
> > +#endif
>
> Hmm I don't see the value to many of the #ifdefs.
It allows platforms to move to TLS support step by step.
> > +(7) Implement _lwp_getprivate_fast() in machine/mcontext.h and set
> > +__HAVE___LWP_GETPRIVATE_FAST.
>
> Perhas wrap these with #ifndef _KERNEL. The x86 kernels are free of inline
> assmebly allowing them to be compiled with compilers other than gcc; this
> block may cause problems.
Which compiler are we talking about? I am using this with a compiler
other than GCC.
Joerg
Home |
Main Index |
Thread Index |
Old Index