I don't know. And neither do you. And that is the problem.
Spawning a thread is trivial. Spawning two copies of the run-loop inside two threads is trivial. Had this been done routinely from day one, running two copies of the same code in each run-loop and comparing the results with each other, and with those from a single threaded run of the same test code, reentrancy errors could have been detected and corrected as they occurred.
By leaving concurrency as an afterthought to be bolted on later, the odds are that whole swaths of the the core code will be built on top of reentrancy conflicts that will be neigh impossible to resolve without major rewrites. And given the low priority, bordering on active hostility, towards concurrency, achieving the will to correct such problems is very unlikely.
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.
| [reply] |
I don't know.
That seems to undercut your assertion that it's too late for Perl 6 or Parrot to do anything sane with concurrency.
... given the low priority, bordering on active hostility, towards concurrency...
Utter nonsense, but well volunteered anyhow.
| [reply] |
| [reply] |
They are not written to cater towards concurrency.
As a simple example, let's consider the Perl5 implementation of LWP::UserAgent. It does not support any concurrency mechanism, and once it blocks while reading from a socket, offers no way to relinquish control to elsewhere in the program. If Perl5 had (from the start) had (say) cooperative multithreading, LWP likely would have been written with that in mind already. It would likely also have emitted messages or callbacks about its progress earlier.
Libraries for Perl6 likewise will not support what is not there from the start.
| [reply] |
| [reply] |