From: Tony Arcieri Date: 2012-07-05T10:33:38+09:00 Subject: Re: Green threads in 1.9.* ? --0015175cdec6ecce5d04c40b22f8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 4, 2012 at 5:11 AM, Xavier Noria wrote: > Then, behind the scenes, they are mapped to native threads in MRI 1.9 and > JRuby. One-to-one. In the case of MRI there's a GIL. I guess technically a > GIL does not mean that MRI is doing the scheduling, it means MRI is holding > a lock, but the kernel schedules the native thread (because it is native). > Maybe there's a gray area in the definition of green thread here, I don't > know. > MRI is still doing the scheduling in 1.9. It runs a timer thread that interrupts running threads after a certain amount of time so waiting threads can run. This way a single thread doing some computationally intensive operation doesn't monopolize the entire VM. -- Tony Arcieri --0015175cdec6ecce5d04c40b22f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4, 2012 at 5:11 AM, Xavier Noria <fxn= @hashref.com> wrote:
Then, behind the scenes, they are mapped to native thread= s in MRI 1.9 and JRuby. One-to-one. In the case of MRI there's a GIL. I= guess technically a GIL does not mean that MRI is doing the scheduling, it= means MRI is holding a lock, but the kernel schedules the native thread (b= ecause it is native). Maybe there's a gray area in the definition of gr= een thread here, I don't know.

MRI is still doing the scheduling in 1.9. = It runs a timer thread that interrupts running threads after a certain amou= nt of time so waiting threads can run. This way a single thread doing some = computationally intensive operation doesn't monopolize the entire VM.

--
Tony Arcieri

--0015175cdec6ecce5d04c40b22f8--