From: Alex Maranda <alex_maranda@...>
Date: 2001-02-12T15:40:03+09:00
Subject: [ruby-talk:10716] Re: Threading model change, proposal

> From what I guess, Python's use of operating system threads results in an
> ugly global interpreter lock which actually means that at any time, only
one
> Python thread can run the interpreter!
Yes. The Python interpreter is not reentrant; that's not as bad as it sounds
since it is customary to release the lock upon entering a blocking syscall
and reacquire it upon exit.

>
> On the other hand, simulating threads in Python results in simpler code
but
I assume that was meant as "simulating threads in Ruby"

> any blocking call in an extension module freezes all Ruby threads at once.
>
> Why would not choose to get the best of both worlds :
>
> * use one main thread which runs the Ruby interpreter
> * use worker threads in which potentially blocking extensions module calls
> would run.
What stops you now from firing up a worker thread for your blocking
syscall(s)? as long as you're not calling back into the Ruby interpreter you
should be fine (the implicit assumption here is that the Ruby interpreter is
not reentrant, which is likely to be the case since it doesn't support
system threads).

>
> This way, the structure of the interpreter and the threading model could
> remain under tight control while allowing blocking native calls to run in
> parallel without blocking the ruby threads.
>
> Sure enough, it is easier said than done !!
> I don't know to which extent the interpreter core would need to be
modified
> in order to support this model.
> Anyone cares to comment ?
Umm. let's review the options here, for any "interpreter", not only Ruby:
1) "green" threads [Ruby as of today]
2) system threads, with a non-reentrant interpreter [Python, global
interpreter lock]
3) system threads, fully reentrant interpreter [no example comes to mind]

The reason Python stopped at 2) is because 3) is hard. The reason Ruby
stopped at 1) is because ...LOL.

The issue with 2) is that one cannot take advantage of multiprocessor
machines, but it will solve your blocking problem with minimal effort. I
don't think you have other option [in Ruby] but to spawn your worker thread
from an extension module (and not call back into the interpreter). The only
reason I'm repeating myself is because last week I've been doing that in a
Python extension module, without owning the lock LOL.

Alex