Which is also why Perl 5 ithreads continue to have scalability issues for the past 15 years!

That statement is as wrong today, as the post you've attached it to was wrong, when you wrote it 15 years ago.

The only scalability issue with iThreads is the implementation (not the model) of shared memory aggregates.

Proof: The following simple demo code starts ARGV[0] threads that each lock/increment/release a shared scalar every 1/100th of second $ARGV[1] times:

#! perl -slw
use threads stack_size => 4096;
use threads::shared;

$|++;

sub usleep{ select'','','',$_[0] }

my $count :shared = 0;

sub doit{
    do{ lock $count; printf "\r[%u] %u\t", threads->tid, ++$count; usl
+eep 0.01 } for 1 .. $_[0];
}

my @t = map threads->create( \&doit, $ARGV[1] // 300 ), 1 .. $ARGV[ 0 
+];

$_->join for @t;

print $count;
[download]

And a run:

C:\test>t-stress 3000 100
300000
[download]

That runs in a tad over 2GB, and once all 3000 threads are running -- a matter of a few seconds -- it consumes less that 1% cpu. That's as, if not more, scalable than any true (kernel) threading interpreted language as I know of, and better than many fully (native) compiled languages.

The fact that you wrote that despicable document without having the understanding to realise what a steaming pile it was, is lamentable.

The fact that 15 years on you haven't learnt enough to realise your mistake and are still promoting it; would be laughable if it wasn't so beyond the pale.

The fact that you are apparently designated (in large part) for specifying the multi-tasking in P6 -- despite being responsible for this other steaming pile of abandonware -- would be scary as well as irresponsible; were it not for the fact that P6 will never challenge even AppleScript or Logo for performance, and is thus useless for anything in the real world; so your brand of throw-in-everything-including-the-kitchen-sink programming will likely never be a serious bottleneck, cos no one will ever use it.