Dan Sugalski wrote:
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.
Yep, though we start up reasonably snapppily, which is nice. :)
- mod_parrot. With Apache 2.0, this would need to be heavily threaded to match the Apache core.
Well... no. Completely non-interacting threads would work fine for this case, I think. (I'm not completely familiar with Apache 2.0, so there may be some things I'm not aware of)
- 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.
Nope, not necessary, though certainly that's one way to do it, and would likely be needed for proper exploitation of a multiprocessor machine. On a uniprocessor machine, though, you'll go further with events and async I/O. It'll certainly be faster than the pure perl 5 webserver, though. (Well, until it's running on Parrot :)
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.
Right, but all of this can be dealt with via mod_parrot running under Apache, which strikes me as the more sensible thing to do--they've already worked out all the network protocol stuff and other grotty low-level bits.
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.
Which is why you use async I/O and events with proper callbacks. :) Using async I/O and events properly will get you better throughput than a threaded solution most of the time. It is, granted, somewhat more brain-twisting if you're not used to it.
In short, I feel that for parrot/perl to be considered for more "serious" applications, it needs industrial strength threading with screaming performance.
It's probably not going to get it by most definitions of "screaming performance" regardless of what emphasis threads get. Parrot's base data structures are too large for anything other than very loosely coupled threads to access things. Too many large things and too many shared resources that the interpreter needs to lock with utter paranoia, because we're guaranteeing that programs running on top of parrot can't screw up the internals by not locking things.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
