If you use a non-threaded perl, you probably will never need my_perl.
Could you please elaborate it? I'm curious why non-threaded perl can do what thread perl can't do. Thanks
I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction
| [reply] |
In a single-threaded perl, there is only one copy of stuff like current working directory, environment etc.
In a multi-threaded perl, each thread needs its own copy of that information.
So, for the single-threaded perl, the PERL_CONTEXT can be known at compile time and linked statically into code. A single static pointer to a struct that contains all the per-thread information is all that is required, because there is only one thread.
In a multi-threaded perl, each function that needs access to the "current PERL_CONTEXT" need to be able to find the appropriate context for the thread it is running in; hence it needs the my_perl variable which tells it which context that is.
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
| [reply] |
Just because in single threaded perl there is no my_perl doesn't mean you can use the types without initializing/having a perl interp set up. SV *s aren't straight malloced from the C lib but come out of a pool the interp maintains.
| [reply] |