From: Andrew Kuchling <akuchlin@...>
Date: 2001-02-13T01:10:02+09:00
Subject: [ruby-talk:10728] Re: Threading model change, proposal

"Alex Maranda" <alex_maranda@telus.net> writes:
> 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

Practically, I'm not sure implementing 3) buys you much.  Threads are
often used for two purposes:

        1) When writing a network server, using threads may make the
        code simpler -- you don't need to write a state machine that
        interweaves the protocol, you just write clearer threaded
        code.  (It's not obvious to me that the threaded code actually
        is clearer or more maintainable, given how tricky it can be to
        find threading bugs, and eventually you probably find yourself
        implementing the state machine for high peformance, but
        anyway...)  

        In this application, the program spends most of its time
        waiting for I/O, and the global interpreter lock would be
        released around the relevant system calls, so it's not much of
        a hindrance.

        2) You're doing heavy computing and want to use multiple CPUs.
        But if you're doing number crunching, you almost certainly
        will not be implementing it in Python/Ruby/some other
        scripting language; you'll likely write it in C or Fortran,
        and write a little wrapper to make it available from your
        scripting language.

        Thus, the global interpreter lock doesn't hurt much because
        most of the computational work is done in low-level wrapped code,
        and the wrapper can release the global interpreter lock.  

Since full threading is complicated and causes increased overhead even
for single-threaded programs, it doesn't seem to be worth the trouble;
the two most common applications for threading don't really benefit
from it.

--amk