On Sun, 27 Mar 2005 18:44:29 -0800, Ross Boylan  
<RossBoylan at stanfordalumni.org> wrote:

> This has been a very interesting thread for me.  I thought squeak did
> time-slicing.  Are other smalltalks the same in not doing timeslicing?
>
The other Smalltalk I know well, VisualWorks, also has 'green threads'. It  
does support native multithreading, but it's too hairy for most to bother.

Personally, I think the value of native multithreading is exaggerated.  
About the only real use I can see for it is multi-processor systems. Look  
at all the restrictions that Java put into threading when starting to  
support native multi-threading for some of the hairiness introduced with  
it...

> What actions, or types of actions, are necessary to yield control?
>
Explicit yields, waiting for semaphores (most I/O), etcetera. In fact,  
unless you're in a tight loop, there's hardly ever reason to explicitely  
yield control.

> Sounds as if it would take a big overhaul to get reliable
> multi-threading.
>
Yes. And if you look at the typical time that's needed to do a 'forced  
context switch' in native multithreading, you gain some minor advantages  
for a very large cost.

Personally, I think that once Squeak has modules/sandboxing/..., it'll be  
almost trivial to assign such a part of squeak (which will be almost like  
a separate VM) to a separate native thread. This would solve most of the  
problems (lockup by one process not relinguishing control being to most  
important one) without a lot of the costs.

> I had understood that squeak was being used (via seaside) for web
> servers.  How do they manage to deal with processing many things at
> once (I'm assuming they do)?
>
You'll be surprised how well 'green threads' work ;)