|Do you know where your variables are?|
Passing my_perl on the stack/register is alot faster than the GLR and SLR and TlsGetValue calls.
Ignoring that I don't know what "GLR and SLR" are -- and you do not bother to explain them -- I'd be interested to see proof of that "much faster". Faster I have no doubts, but much faster?
And I counter that assertion with: speed isn't everything.
Burdening every function, and every programmer, with the need to accommodate a 'pass-through variable' and relying upon the optimiser to make it disappear when not required -- all to save what effectively becomes something like mov rax, GS:[8*rcx+0x2c] -- is short-sighted in the extreme.
And wrapping it over in a bunch of "trick" macros make the programmer burden -- via cognitive disconnection -- even worse.
I wouldn't. Just because I took the OP to mean that; doesn't mean that I think that it is a good idea, or even possible.
I only attempted to answer -- at perhaps a superficial level -- the OPs question: "I'm curious why non-threaded perl can do what thread perl can't do.". Naught more.
Which is why I think your post would have been better directed at the alternative you suggested.
GObject and Perl's GC systems have many similarities. ... I am saying that would be a bad choice.
Then why mention it? No one else did.
Aren't you just as guilty of misdirection by bringing it up and leaving it hanging as the guy that suggested: "you'll be fine so long as you don't use threads"? Which seems to be the focus of your posts.
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.