[#10209] Market for XML Web stuff — Matt Sergeant <matt@...>

I'm trying to get a handle on what the size of the market for AxKit would be

15 messages 2001/02/01

[#10238] RFC: RubyVM (long) — Robert Feldt <feldt@...>

Hi,

20 messages 2001/02/01
[#10364] Re: RFC: RubyVM (long) — Mathieu Bouchard <matju@...> 2001/02/05

[#10708] Suggestion for threading model — Stephen White <spwhite@...>

I've been playing around with multi-threading. I notice that there are

11 messages 2001/02/11

[#10853] Re: RubyChangeRequest #U002: new proper name for Hash#indexes, Array#indexes — "Mike Wilson" <wmwilson01@...>

10 messages 2001/02/14

[#11037] to_s and << — "Brent Rowland" <tarod@...>

list = [1, 2.3, 'four', false]

15 messages 2001/02/18

[#11094] Re: Summary: RCR #U002 - proper new name fo r indexes — Aleksi Niemel<aleksi.niemela@...>

> On Mon, 19 Feb 2001, Yukihiro Matsumoto wrote:

12 messages 2001/02/19

[#11131] Re: Summary: RCR #U002 - proper new name fo r indexes — "Conrad Schneiker" <schneik@...>

Robert Feldt wrote:

10 messages 2001/02/19

[#11251] Programming Ruby is now online — Dave Thomas <Dave@...>

36 messages 2001/02/21

[#11469] XML-RPC and KDE — schuerig@... (Michael Schuerig)

23 messages 2001/02/24
[#11490] Re: XML-RPC and KDE — schuerig@... (Michael Schuerig) 2001/02/24

Michael Neumann <neumann@s-direktnet.de> wrote:

[#11491] Negative Reviews for Ruby and Programming Ruby — Jim Freeze <jim@...> 2001/02/24

Hi all:

[#11633] RCR: shortcut for instance variable initialization — Dave Thomas <Dave@...>

13 messages 2001/02/26

[#11652] RE: RCR: shortcut for instance variable initialization — Michael Davis <mdavis@...>

I like it!

14 messages 2001/02/27

[#11700] Starting Once Again — Ron Jeffries <ronjeffries@...>

OK, I'm starting again with Ruby. I'm just assuming that I've

31 messages 2001/02/27
[#11712] RE: Starting Once Again — "Aaron Hinni" <aaron@...> 2001/02/27

> 2. So far I think running under TextPad will be better than running

[#11726] Re: Starting Once Again — Aleksi Niemel<zak@...> 2001/02/28

On Wed, 28 Feb 2001, Aaron Hinni wrote:

[ruby-talk:10728] Re: Threading model change, proposal

From: Andrew Kuchling <akuchlin@...>
Date: 2001-02-12 16:10:02 UTC
List: ruby-talk #10728
"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

In This Thread