Truly compiled lightweight threads would indeed be faster than interpreted threads, but perhaps interpreted threads would be "fast enough". Given that you're slowed to network speeds anyway (consider that a T1 is relatively slow compared to bus speeds, which are relatively slow compared to internal processor speeds) I think that the issue becomes one of responding to multiple requests "fast enough".
Bob Jarvis The Timken Company
-----Original Message----- From: Dick Karpinski [SMTP:dick@cfcl.com] Sent: Wednesday, June 30, 1999 1:05 AM To: squeak@cs.uiuc.edu Subject: Re: [ALL] Lobbying - Smalltalk KILLER APP!
What a lovely vision!
But I don't understand how an interpreted server can have processes as lightweight as compiled lightweight processes. Is this after some hypothetical compiler has sped up frequently used code paths or something? I think I understand parts of that direction, but it does not seem to get much discussion here.
Dick
The compiled-ness or not of the code is almost irrelevant to the lightweightedness of the thread system. The essence of lightweight threads is that it gives you much of the usefulness of a separate process without much of the setup cost. Thus a Smalltalk Proces is actually a rather good example of what most people would mean by a lightwieght thread - it costs almost nothing to setup and operate. A Unix process fork on the other hand is quite heavy weight since it involves basically copying the entire process space of the spawner process, and then full scale process context switches in use. Various optimisations have been made over time like memory copy-on-write, but it still costs quite a bit. The context swapping cost might possibly be better with very optimised compiled code, but don't forget that the context switching code in Smalltalk is a primitive that should be just as well compiled...
tim
squeak-dev@lists.squeakfoundation.org