>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
> 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. you missed at least two major designs a pure parrot event loop system. if it has true async file i/o (which dan has promised by using kernel threads but not parrot threads), you can do it all in one process and one thread and not have the sync/locking thread overhead or the process context switch overhead. use an apache front end to a backend design as with the above. then you get all the apache stuff you want and you get a fast backend with no mod_perl craziness, no parrot level thread issues, etc. the moral is, parrot threads are not the be-all/end-all solution. my favorite query about threads is how well do they scale beyond one box? (even dan can't fix that problem. :) > 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. that is not the only way as i have pointed out. it is just a way that is promoted heavily (like java). events if done correctly are generaly faster than threads and use much less ram (no stack context created for each thread). and blocking stuff can be solved with true async file i/o support (via direct kernel support or kernel threads) and good old forking (preforked backend blocking servers and doing comm with either pipes or shared ram). you just have to think outside the threaded box. > In short, I feel that for parrot/perl to be considered for more > "serious" applications, it needs industrial strength threading with > screaming performance. it should have fast threads but it doesn't NEED them. it NEEDS a solid event loop and real async file i/o (which dan will deliver). then you can solve things like this even faster than with parrot level threads. just plugging events, uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
