Re^5: Backend diversity for Rakudo

My personal view is that if Perl6 (and Parrot) don't have built-in threading (or AnyEvent-style message passing) from day one, it will be immensively hard to retrofit all existing libraries to play well with that. So there really is a clock ticking against Perl6+Parrot on that topic, as having a solid IPC foundation that is not fork is really necessary for a language nowadays. It's a bit sad that nobody seems to share my view on the Perl6+Parrot teams, at least enough to push the issue.

I'm not convinced that threads sharing memory on the language level are really the way to go. I'm very fond of simply passing data as messages between all threads. I found that most race conditions do not arise at all when structuring my execution paths so they simply send and receive messages.

Comment on Re^5: Backend diversity for Rakudo

Replies are listed 'Best First'.
Re^6: Backend diversity for Rakudo by BrowserUk (Patriarch) on Aug 17, 2010 at 19:53 UTC
My personal view is that if Perl6 (and Parrot) don't have built-in threading (or AnyEvent-style message passing) from day one, it will be immensively hard to retrofit all existing libraries to play well with that. That's my conclusion also. Too little, too late.	[reply]
Re^7: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 20:41 UTC
Which Perl 6 and Parrot libraries have bugs which concurrency or parallelism will expose?	[reply]
Re^8: Backend diversity for Rakudo by BrowserUk (Patriarch) on Aug 17, 2010 at 21:13 UTC
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. RIP an inspiration; A true Folk's Guy	[reply]
Re^9: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 21:31 UTC
Re^10: Backend diversity for Rakudo by BrowserUk (Patriarch) on Aug 17, 2010 at 22:21 UTC
Some notes below your chosen depth have not been shown here
Re^8: Backend diversity for Rakudo by Corion (Patriarch) on Aug 17, 2010 at 21:05 UTC
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]
Re^9: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 21:28 UTC
Re^6: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 18:53 UTC
It's a bit sad that nobody seems to share my view on the Perl 6+Parrot teams, at least enough to push the issue. I share your views. Anyone interested in working on this has my full support.	[reply]