On Tue, 23 Dec 2003, Uri Guttman wrote: > >>>>> "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. :)
Well, Dan's type 2 threads sound fairly like a message-passing system, in which case it would hopefully be possible to have them seamlessly interface with MPI or PVM; in which case, scaling beyond one box is no problem (well, at least until latency, bandwidth and/or Amdahl's law start to bite...) Simon
