Actually I am aware of occupying your precious time by explaining to me things

My time isn't particularly precious these days, and I'm happy to talk about threading. But like Stephen Fry, I do get rattled a little by someone who just keeps repeating the same thing over and over. ("Ceiling|"; "They're heavy!")

iThreads are "heavy" compared to kernel threads in low-level languages like C. This is undeniable. But that isn't a reason to either reject them or decry them. Trucks are heavy compared to cars, but that's because they need to be to perform their function. So it is with iThreads.

And so it is with integers in Perl. They are heavy compared to integers in low-level languages like C.

On my 64-system: In C, a million (native) integers occupies 8MB. In perl, those same million integers occupy 32MB.

But we forgive Perl that weight because of all the value-add that weight gives us. Numbers that transparently convert themselves from text to binary, integer to floating point, and back again as the program demands.

No mess of text to binary conversion routines: _tstof(), atof(), _wtof(), _tstoi(),  atoi(), _wtoi(), _tstoi64(), _atoi64(), _wtoi64(), _tstol(), atol(), _wtol(), _ttoi(), _wtoi(), _ttoi64(), _atoi64(), _wtoi64(), _ttol(), atol(), _wtol() and corresponding mess of binary to text conversion routines: _itoa(), _i64toa(), _ui64toa(), _itow(), _i64tow(), _ui64tow(), _ultoa(), _ultow(), _ultoa_s(), _ultow_s().

We recognise the costs of Perl's dynamic nature, and recoginise that they are outweighed by the benefits it brings to the simplicity of its programs and productivity of its programmers.

Similarly, the 'weight' of iThreads brings huge benefits.

• Sheer simplicity.

  For many, many uses, a single keyword: async() is all you need to get access to true, scalable concurrency

• Safety.

  Need to do two things concurrently? Throw one of them into an async{ ... }; block and you've got it. Done and dusted.

  No fears about accidental sharing. (Mostly) no need to lock anything. No deadlocks, livelocks or priority inversions to think about. It just works,

• Usability.

  For the common, simple cases, adding concurrency to your single threaded code is almost trivial.

• Perl has them.

  Do not under estimate how unique a dynamic language with usable, scalable, workable threading is.

As implemented, iThreads are not perfect by any stretch of the imagination. There are many ways in which that implementation could be improved. But for dynamic languages, the iThreads model is the only way to go, and will be much copied in the future.

Indeed, I believe that when the dust settles, compiled languages will provide threading that offers a similar model. Ie. Explicit-only shared state. The benefits of shared state concurrency, but only when you want it. It is almost common sense really. Sharing everything is just so dangerous.

Human beings are very bad at remembering what they've used and where. But compilers are single-minded and relentless at tracking such details. So, let the compiler yell at us and stop working if we start accessing the same data from multiple threads. Have it force us to mark shared data as such and so force us to think about the requirements and consequences of doing so. Then, anything not explicitly marked is safe, requires no locking, and runs at full speed.