ara.t.howard wrote:
> consider these facts
> 
> - green threads are inexpensive to create compared to native threads
> - green threads can help throughput a lot where io is concerened iff
> select is a good paradigm for scheduling activity (imagine many network
> connections)
> 
> - native threads are relatively expensive to create
> - native threads have the same bottleneck on io that green threads have:
> you can physically only write to disk with the number of disk
> controllers you have and reading from sockets may still be limited to
> the speed of the person on the other end
> 
> green threads are good for something and native threads are good for
> somethings.  fortunately in ruby it's extremely easy to farm out tasks
> to another process and use ipc with
> 
>   slave = Slave.new{ Server.new }
> 
> so we get the best of both works if we want it.  people will miss green
> threads when they are gone - am i the only one who remembers not being
> able to stop java's native threads?

Well ... I think we should have *both* green threads (i.e., a built-in
thread scheduler in a single Ruby process) and native threads (i.e., the
Linux "clone" operation creating a separate lightweight process sharing
a memory space). On top of that, we should have Erlang-style lightweight
Ruby processes communicating via message passing, something resembling
MPI and probably something resembling OpenMP. And of course there's dRB
and Rinda -- they aren't going away, are they?

Unfortunately, the whole world doesn't use the Linux kernel and the GCC
compilers, but for the part of the world that *does*, all of this is
doable via C-language libraries, and I'm guessing most of it *has* been
done. I know there's a "ruby-mpi" project, for example, although it
looks like it hasn't been touched in a couple of years and might be
orphaned.