They'll live. Python and Ruby both have a single global interpreter lock and nobody much cares.
People won't move to parrot because of signal or thread support, or because we give them a cookie. People will move to parrot because it runs perl 6, or because it gives them cross-language support for perl, python, and ruby, or because it's an easy target to write a custom language for.
Threads are useful, they're important, and they will be supported properly. All indications are, however, that most programs will be non-threaded, and decisions about the design are made with that in mind.
A major use of many languages these days is web services. In the parrot world, I see three possible ways for this to happen.
- CGI/Exec. No problem to make parrot work, but the performance issues with this are well known.
- mod_parrot. With Apache 2.0, this would need to be heavily threaded to match the Apache core.
- A pure parrot web application server (PPWAS) that can compete directly against the EJB/.NET crowd. This would obviously need heavy threading with high performance.
If parrot is fast enough at threading and general computation, I'd see a PPWAS as an amazing attractive target platform.
- Open Source Specs & Code.
- Multiple native languages
- Could relatively easily port your php & jsp web apps over.
- Ability to cross talk between your various languages.
I'd also point out that most all of the projects I've worked on which were performance sensitive, they tended to favor a threaded approach to easily work around something that blocks (UI, I/O, etc). Storing state information to get around this is a major pain in the butt.
In short, I feel that for parrot/perl to be considered for more "serious" applications, it needs industrial strength threading with screaming performance.
That's my $0.02 -- Rod
