Perhaps you have little experience with programming with real threads ...
You know that is not the case, so why suggest it might be?
... so much of my exposition is foreign to you?
Not at all. I've seen people get themselves in horrible tangles using threads and semaphores and mutexes in C, assembler Java et al. Indeed, I've done it myself way back when.
I've also watched the industry trying to 'fix' the problems with ever more complicated locking & exclusion mechanisms: spin locks, recursive mutexes, ever more elaborate deadlock avoidance schemes, with varied and patchy success. But, as I've said many times, the way to avoid these problems, is to not write code that creates the possibility for them in the first place. And that isn't hard to do, even in C or assembler.
But all this ancient history about a threading in other languages has no bearing on threading as it exists today, in Perl. You might just as well bring up the Pentium bug and cite it as a reason for avoiding floating point math in Perl today.
... the motivation is reducing process overhead ...
Then why use Perl? C carries far less overhead. In assembler you could probably squeeze everything you've ever wanted to do into less than the startup cost of perl(.exe). But it obviously would come at a cost.
We use Perl because, for all but the most demanding of application environments--embedded systems, maybe trading systems and the like--the trade-off of memory versus programmer productivity is utterly worth it. That is no different to accepting that Perl's hashes are more memory hungry than C++ hash_map. Or Perl's arrays are far more memory hungry than C arrays. The trade is worth it.
And so it is with ithreads. I have a four core system. There is rarely ever any point in running more than four concurrent threads. And when there is, it is at most 8 or maybe 16.
Checking the memory consumed by 4 threads: c:\>perl -Mthreads -E"@t= map async(sub{ 1 }),1..4; sleep 100", it comes in at 6.4MB on my 64-bit system.
For 16 threads: perl -Mthreads -E"@t= map async(sub{ 1 }),1..16; sleep 100" it's 12.6MB
Checking a bare perl startup c:\>perl, it is 3.2MB.
So that's between 0.6 & 0.8 MB per thread "overhead". That is a piddling small amount to be worrying about on systems with at least 2GB of memory. And when another 2GB will cost less than half your hourly rate.
Sure, I can make them use more:>perl -Mthreads -E"$x='x'x1e6; @t= map async(sub{ 1 }),1..16; sleep 100" comes in a 2.6MB per thread.
But if I do it this way:perl -Mthreads -E"@t= map async(sub{ 1 }),1..16; $x='x'x1e6; sleep 100" it comes back to just 0.7MB per thread.
Fiddling around trying to intersperse your linear algorithms with sufficient cede points to ensure that they all get a fair shout at the cpu--like trying to manage traffic by adjusting the speeds of all the vehicles so that they miss each other at junctions--for the sake of 1/2 an hours pay? Only to find that 3/4 of your processor cycles are being wasted. That's ... just not the Perlish trade off.
... you missed almost completely the point and have no interest in discussing any of the other "issues".
If by "other issues" you mean Hammer House of Threading Horror stories in other languages, in bygone eras, written with dubious, antiquated coding practices. You're right! I have no interest.
Likewise, if you want to argue that you can do something using Coro that only uses 5 MB of memory compared to an equivalent threaded solution (written by me!) that used 20MB or even 50MB. Then I again have no interest.
If you mean trumpted up, hopelessly stacked, utterly meaningless benchmarks of Coro versus ithreads claiming (and utterly failing) to perform a cpu-intensive, mat-mult algorithm--that BTW, runs 1000 times more quickly (than either) when run as straight-forward linear code. I have no interest.
If you have a real, current case where a Perl program using ithreads has deadlocking issues, or exhibits priority inversion then please post it. I'd be more than please to show you the error of your ways.
Or even if you have a piece of working Coro code (GUIs and comms. servers excluded), that you think either: cannot easily be done better using threads; or will create deadlocking issues if coded using ithreads; then post it and we can compare solutions.
In fact, pretty much anything that is Perl and relates to issues with ithreads I am more than willing--even anxious--to explore. With the proviso(*) that it starts and ends with a comparison of working code that we can all run.
(*)This proviso simply because anything else is just your word versus mine. Your analogy versus mine. Your insults, innuendos and claims versus mine. And we both know where that leads. Exactly nowhere useful.
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.