On Tue, 23 Dec 2003, Uri Guttman wrote:
>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:> the moral is, parrot threads are not the be-all/end-all solution. my
> 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.
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...)
Arguably any method call could be a message that gets passed off to the other end of the world, though some of the designs of the method lookup system make that somewhat more difficult than we might otherwise like. (The fetch method PMC, then invoke method PMC, means that a distributed object system needs to have the object return a proxy method call PMC, where a single call-on-object system could embed the proxying into the object itself, but that's a minor issue)
But yeah, there's no requirement that the receiving interpreter need be on the same system, given how loosely coupled a type 2 thread system is and the fact that calls are all pass-by-value. A call could well serialize up the PMC contents and fire them across the wire to a remote interpreter or something--there'd not really be any way for the calling interpreter to know. Or much reason for it to either, I suppose.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
