From: Xavier Noria Date: 2012-07-04T21:59:38+09:00 Subject: Re: Green threads in 1.9.* ? --047d7b15ac61655a4504c4009a22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2012 at 2:45 PM, Peter Zotov wrot= e: Xavier Noria =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 04.07.2012 16:41: > > On Wed, Jul 4, 2012 at 2:30 PM, Peter Zotov *= * >> wrote: >> >> Ruby 1.9 uses kernel threads and does not have green threads. >> >>> There is nothing like Erlang's lightweight processes in Ruby (or, for >>> that matter, in most of the languages). >>> >> >> >> That is clear, but the definition of green thread depends on who schedul= es >> them. >> >> Is the GIL acting as a scheduler? Has MRI logic about what to lock next >> therefore scheduling in practice *among the threads in its process*? Or = is >> my conjecture right that locking is mostly dumb and that ultimately the >> kernel is the scheduler because the thread is native? >> > > The OP's problem is not the scheduler itself but the associated system > resources. > You can create 20k Erlang processes ("threads"). You cannot create 20k > pthreads. Just that. Looks so also to me, but Ilya's post makes that clear (and it is a known characteristic of MRI 1.9)... why the followup then after I linked to the post? --047d7b15ac61655a4504c4009a22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2012 at 2:45 PM, Peter Zotov <whitequark@whitequa= rk.org> wrote:

Xavier Noria =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 04.07.2012 16:41:

On Wed, Jul 4, 2012 at 2:30 PM, Peter Zotov <whitequark@whitequark.org>wrote:

Ruby 1.9 uses kernel threads and does not have green threads.
There is nothing like Erlang's lightweight processes in Ruby (or, for that matter, in most of the languages).


That is clear, but the definition of green thread depends on who schedules<= br> them.

Is the GIL acting as a scheduler? Has MRI logic about what to lock next
therefore scheduling in practice *among the threads in its process*? Or is<= br> my conjecture right that locking is mostly dumb and that ultimately the
kernel is the scheduler because the thread is native?

The OP's problem is not the scheduler itself but the associated system<= br> resources.
You can create 20k Erlang processes ("threads"). You cannot creat= e 20k
pthreads. Just that.

Looks so also to me, b= ut Ilya's post makes that clear (and it is a known characteristic of MR= I 1.9)... why the followup then after I linked to the post?


--047d7b15ac61655a4504c4009a22--