On Mon, Mar 31, 2008 at 7:45 AM, Francis ANDRE <[EMAIL PROTECTED]> wrote:
> >> Do you have any suggestions or preferences about a particular TLS
> >> approach? I'm all for fast, but I tend to lean towards a consistent
> >> (single) clean approach, even it it's not the fastest approach.
>
> What would you think about using the zthread package as general rule and
> using
> optimal hand coded part for optimization??
> http://zthread.sourceforge.net/
>
> Francis
I'm not familiar with that project, so I can't really comment. What
would be the advantages of using it?
-Nathan
>
> Pavel Rebriy a écrit :
>
>
> > Nathan,
> >
> > TLS access is a performance critical function, that why unified (single,
> > clean) approach could have 20-30% of performance degradation on some
> > benchmarks.
> >
> > On 31/03/2008, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> >> On Sun, Mar 30, 2008 at 4:41 PM, Gregory Shimansky
> >> <[EMAIL PROTECTED]> wrote:
> >>> On 29 марта 2008 Nathan Beyer wrote:
> >>> > In open/hythread.h there is the following bit of code.
> >>> >
> >>> > #ifdef PLATFORM_POSIX
> >>> > extern __thread hythread_t tm_self_tls;
> >>> > #else
> >>> > extern __declspec(thread) hythread_t tm_self_tls;
> >>> > #endif //PLATFORM_POSIX
> >>> >
> >>> >
> >>> > hy_inline hythread_t VMCALL hythread_self() {
> >>> > return tm_self_tls;
> >>> > }
> >>> >
> >>> > From what I know at the moment, the use of '__thread' isn't a POSIX
> >>> > standard, but rather a gcc extension and '__declspec(thread)' is a
> >>> > MSVC thing, so the check isn't quite correct. Neither of these works
> >>> > on MacOS X and from what I've been able to gather, it shouldn't work
> >>> > on FreeBSD, but I can't confirm that. In any case, I was looking at
> >>> > implementing this for MacOSX and FreeBSD using pthread_key_t. It
> >> seems
> >>> > like that could be used for other (all?) platforms as well. Any
> >>> > thoughts on that?
> >>>
> >>> AFAIK there are plenty of different implementation for getting TLS in
> >> DRLVM's
> >>> implementation of hythread. There are fast ways like those you've
> >> mentioned,
> >>> slow ways using APR and pthread and very fast ways using inline
> >> assembly.
> >>> All of them are quite messed up right now and need some cleaning. The
> >> mess is
> >>> with different defines that rule the whole stuff - it is not always
> >> clear
> >>> which define set is used for a particular implementation on a given
> >> platform.
> >>
> >>
> >> I would agree that the defines are a bit of a mess or at least seem
> >> like it at times.
> >>
> >> Do you have any suggestions or preferences about a particular TLS
> >> approach? I'm all for fast, but I tend to lean towards a consistent
> >> (single) clean approach, even it it's not the fastest approach.
> >>
> >>> --
> >>> Gregory
> >>>
> >
> >
> >
>
