From: Luc Heinrich <lucsky@...>
Date: 2001-12-20T05:45:26+09:00
Subject: [ruby-talk:28985] Re: A Ruby programmer walked into a bar and	ordered a Ruby-Thread

On 19/12/2001 15:46, "Harry Ohlsen" <harryo@zip.com.au> wrote:

> A little investigation shows that what appears to be happening is that
> the first of two threads that is created has taken complete control of
> the CPU, thus starving the main thread and not allowing any further
> processing.

To quote the Pickaxe:
(http://www.rubycentral.com/book/tut_threads.html and page 113 of the
printed version)

"[Ruby threads] are totally in-process, implemented within the Ruby
interpreter. That makes the Ruby threads completely portable---there is no
reliance on the operating system---but you don't get certain benefits from
having native threads. You may experience thread starvation (that's where a
low-priority thread doesn't get a chance to run). If you manage to get your
threads deadlocked, the whole process may grind to a halt. And if some
thread happens to make a call to the operating system that takes a long time
to complete, all threads will hang until the interpreter gets control back."

So, although quite unfortunate, this would be some kind of an "expected"
behavior, I guess.

Which leads me to the same question I recently asked on the #ruby-lang
channel: what kind of impact would have the introduction of native threads
in Ruby ?

I guess that portability would suffer and, as somebody mentioned, quite a
lot of changes deep in Ruby guts. So how about keeping Ruby threads as is,
and adding native threads as an extension ?

Just wondering...

-- 
Luc - lucsky@mac.com