All right, all right.  I've learnt a lot.  Particularlly that green
threads are not that bad.
But may I insist on a few issues.
That code snippet, the one that triggered all this.  A shared queue
being filled by two different processes was always sequentially
filled, it did require the #yield.  How do you know when it is sound
to include the #yield in your code or not?
Why does it seem that the rest of the world abandoned green threads?
Why didn't the Java people stick to green threads for instance? 
Where's the catch?
Why are same priority processes not preemtable in Squeak?

On 4/14/05, Colin Putney <cputney at wiresong.ca> wrote:
> Ramiro Diaz Trepat wrote:
> > Cees, my point is not mooted.  Most web applications use threading.
> > Most of the servers that run our applications today are Dual Opterons
> > running Linux.
> > Nobody yet answered why they think it's all right to have to do
> > Processor yields in your code for threads of same priority.
> > Are you really that conservative, I mean to defend teeth and claws
> > anachronic green threads?
> > Wouldn't you be happy with a preemtive system that worked fine?  Not
> > having to do fake load balancing haviing different images doing
> > different jobs? Not having to ever write Processor yield?
> > come on... what would be wrong with native threads?
> 
> Ramiro,
> 
> My web site runs two web applications written in Squeak. Both of them
> are multi-threaded, and neither of them calls #yield. It runs on a
> multi-processor box, along with apache, DNS and mail servers, and under
> load none of the processors is wasted. I'm quite happy with this system.
> It's preemptive and works fine.
> 
> Here's what would be wrong with native threads:
> 
> - They would be less efficient than Squeak Processes. A Process is very
> lightweight, and context switches in Squeak are very cheap. A context
> switch using native threads is very expensive by comparison.
> 
> - They would be less scalable than Squeak Processes. Squeak can run 10K
> Processes in an image with ease. You just can't do that with native threads
> 
> - They wouldn't run identically on all platforms. A single Squeak image
> runs identically on all the platforms, and that includes directly on the
> hardware, without an OS. With native threads, you can approximately the
> same behaviour, on some platforms.
> 
> - Using native threads makes garbage collection really difficult,
> particularly if you want to minimize pauses. Given that Squeak is
> commonly used in multimedia applications, where GC pauses interfere with
> smooth audio processing and animation, native threads would be problematic.
> 
> So, given that what we have today works fine for any practical need, and
> that moving to native threads would take away capabilities that we
> currently have, I see no reason to do it.
> 
> This is my last post on this topic. If you are truly interested using
> Squeak for your business I'll be happy to talk about how to do that.
> 
> Colin
> 
> 


-- 
http://neosmt.com