2011/3/6 Charles Oliver Nutter <headius / headius.com>:
> 2011/3/5 J=F6rg W Mittag <JoergWMittag+Ruby / googlemail.com>:
>> (Interestingly, I haven't seen any implementations with concurrent
>> green threads, which IMO is the best kind of threads. Rubinius
>> originally planned to do concurrent green threads, but they never did.
>> They started off with serialized green threads, then switched to
>> serialized native threads and are currently in the process of
>> switching to concurrent native threads.)
>
> Some JVMs started out with M:N threading (which I think is what you
> mean by concurrent green threads, i.e. M green threads mapped to N
> native threads, so you can get concurrency but also lightweight
> threading), but as far as I know they all abandoned it due to the
> overhead of managing both concurrency and lightweight thread contexts.

It would also seem inefficient from the point of view that the OS does
already do all the tasks necessary for thread scheduling.  So adding
another layer which duplicates these things would really only make
sense if the scheduling inside the process could benefit from
knowledge about the application's (Ruby interpreter in this case)
behavior and thus yield significantly better results than relying on
OS scheduling does.  But, as you said, it's really the question
whether there is a runtime benefit and whether it's worth the added
complexity in the interpreter.

> If there are any green-threaded JVMs out there, it's likely they're
> too slow to be useful; native JIT is hard to implement atop green
> threads, so green-threaded JVMs in the past were mostly interpreted.

Thanks for all those insights, Charles and J=F6rg!

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/