in reply to Re^10: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
in thread Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

This requires (at least the last time I looked in the linux pthreads library) the current stack pointer to be compared against the stack range allocated to each current thread, to determine which thread we are.

As an aside, I don't understand why the context needs to be passed from function to function to function anyway?

On windows, you allocate a global uint, assign the return from DWORD tlsindex = TlsAlloc() to it at process startup, and then whenever thread needs access to its TLS, it calls TlsSetValue( tlsIndex, pointer ); and struct context p = TlsGetValue( tilsIndex );.

And I read that pthreads has the equivalent pthread_key_create(), pthread_setspecific(), pthread_getspecific() calls which perate in a similar fashion.

So why does context have to be passed around, and reasserted in every routine, even those that (apparently) do not make any ised of it or what it points to?

I really do not understand why the perl context cannot be retrieved from TLS when it is needed, rather than passed around like a baton?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^12: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by dave_the_m (Monsignor) on Aug 29, 2012 at 20:47 UTC
    I really do not understand why the perl context cannot be retrieved from TLS when it is needed, rather than passed around like a baton?
    Because on linux pthreads at least, retrieving a value from TLS is very expensive (using the "match the SP to a thread" trick). Passing an extra parameter is a lot quicker.

    As to why they don't reserve a register for it, you'd have to ask them. But I would speculate that it boils down to the fact that you can't assume that all code from all libraries compiled by all the different possible compilers on all the different platforms all know and agree that they're not allowed to touch register X. If this had been agreed on day 1, then maybe; not so much now.

    Dave.

[reply]
Re^12: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by bulk88 (Priest) on Aug 29, 2012 at 21:04 UTC
    The perl context is passed around as pTHX and aTHX as a C param. Only legacy/abandoned XS code and the C Lib emulators in Perl call Perl_get_context() nowadays. Not using PERL_NO_GET_CONTEXT for all XS code in the last 10 years is a sin. Then again, most CPAN authors don't care (I'm staring at you Win32:: namespace).
[reply]
      The perl context is passed around as pTHX and aTHX as a C param.

      That's even worse.

[reply]
[reply]

      Not using PERL_NO_GET_CONTEXT for all XS code in the last 10 years is a sin.

      Right, its a sin not to posses secret knowledge -- PERL_NO_GET_CONTEXT site:perldoc.perl.org

      Then again, most CPAN authors don't care (I'm staring at you Win32:: namespace).

      Right, because non-threaded perls are the bees-knees on win32, and PERL_NO_GET_CONTEXT is reported to all these non-caring sharers of code ( PERL_NO_GET_CONTEXT site:rt.cpan.org, )

[reply]
        Right, its a sin not to posses secret knowledge
        So what you're saying is that its a sin to have a facility that has been fully documented in perlguts.pod since 5.6.0, 12 years ago?

        Dave.

[reply]

In Section Meditations