threads.xs is 5% simpler to initialize

Man. Are you incapable of rational thought? (Scan forward to 12.25 seconds and watch for 4 minutes.)

for sure, you already saw this famous article

Yes. And I know that Liz didn't know what she was talking about.

(Take a close look at the crap modules she littered the Thread::* namespace on cpan with if you doubt this. )

And neither do you. Your misunderstanding (and her's) is manifest.

Actually this unfortunate design has its historical explanations - there were 5005THREADS, which were developed in pre-5.6.0 perl and were designed to be lightweight. this stuck, fo rsome reasons, and 'ithreads' were added quickly as easier solution.

And that is the final nail of proof in your 'threading expertise' coffin. You simply haven't taken the time, (nor any time it seems), to attempt to understand the subject on which you are pontificating.

5005 threads were kicked into touch because it was impossible to make Perl's 'fat' data structures safe. Not just from user abuse, but even internally.

Ithreads are not an 'evolution of 5005 threads.

Do you know how this threading is done in Python and Ruby, BTW?

Yes. Both implement forms of 'green threads', which is to say, user space threading. IN other words, they run as a single OS thread, and implement a (crude) internal scheduler within that single OS thread.

Which means they rely upon a global interpreter locks. Which means they are very slow. Not just for access to shared state, but all state.

And they do not scale.

Because they use user space threading, to the OS they run under, they are a single threaded process. Which means they can only ever utilise one core at a time. No matter how many cores are available, or how many (pseudo)threads the program spawns, they are only ever going to execute one instruction at a time.

Bottom line, in the words of Python users Python threads suck!. Read the entire thread. Look for the acronym "GIL". Try and understand.

In the words of Ruby users, "Threads suck in Ruby. They are not native threads but are programatic threads in the ruby engine. If you have any thread that tries to open a socket, and the socket destination is not there, it will take a while for the socket to time out. During this wait, the whole ruby engine is frozen."

Perl 5 is (to my knowledge) the only dynamic, interpreted language that supports true, concurrent, scalable (kernel-based) threading, Imperfect for sure, but far less imperfect than other dynamic languages. And far simpler and more productive to use than any compiled languages.

This thread is more than deep enough. If you want to continue to display your ignorance of this subject, you can do so as a monologue.