Hi guys!

Ramiro Diaz Trepat <ramirodt at gmail.com> wrote:
> 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?

Typically, if you create Processes (using fork or whatever) then you
probably would have a clue of their priorities. One of the main problems
here IMHO is that the class comments of Process and ProcessorScheduler
should explain the model, which they don't. We should fix that.

> Why does it seem that the rest of the world abandoned green threads?

That is not really true. :) Ruby has "green" threads AFAIK, Perl seems
to have multiple variants, and google easily shows interest in
non-native threading stuff, for example:

	http://www-106.ibm.com/developerworks/linux/library/l-pythrd.html

> Why didn't the Java people stick to green threads for instance? 

Ehm, this is also not "true". Let's have a look at the volvano report
(2003, possibly the newest):

	http://www.volano.com/report/index.html

As you can see, JRockit (a former Swedish company bought by BEA) which
is a commercial server side VM, proves to scale much better in some
areas than the competition using what they call "thin threads" which
seems to be groups of "green" threads mapped onto a few OS native
threads.

I quote from the conclusion:

"At 10,000 connections, BEA JRockit 3.1 on Windows has 14 times the
throughput of any other Java platform---by far, the best network
scalability I have ever tested. While other Java vendors waited for
better threading support in the operating system or new programming
interfaces for the application, the JRockit team solved the Java threads
problem right where it originated. The results are remarkable, and BEA
made a wise purchase."

So... the answer is no - native threads are not the answer to
scalability. On the *contrary*.
 
> Where's the catch?
> Why are same priority processes not preemtable in Squeak?

This has been answered by others. Having an easy way of introducing a
time slicer Process that sits above a group of lower prio Processes
would of course be a nice thing to have. Care to help out? :)

regards, göran