From: Robert Klemme Date: 2011-03-07T17:15:17+09:00 Subject: Re: question: threads behaviour 2011/3/6 Charles Oliver Nutter : > 2011/3/5 Jörg W Mittag : >> (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örg! Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/