[#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:10762] Re: Threading model change, proposal

From: "Gaston Fong" <gastonfong@...>
Date: 2001-02-13 00:40:02 UTC
List: ruby-talk #10762
"Cameron Laird" <claird@starbase.neosoft.com> a 馗rit dans le message news:
4DAB7C073C4E7F7E.939B65A2F094403A.B5AF9687CDD913D7@lp.airnews.net...
> In article <LAW2-F290jCRo1OKUTG00007b0c@hotmail.com>,
> Ben Tilly <ben_tilly@hotmail.com> wrote:
> >Andrew Kuchling <akuchlin@mems-exchange.org> wrote:
> >>
> >>"Ben Tilly" <ben_tilly@hotmail.com> writes:
> >> > I suspect that the most common appliation for threading is
> >> > to allow a GUI to be responsive even when the program is
> >> > busy doing something else. ...
> >Multi-threading with real threads is valuable, and can
> >work just fine even if only one thread talks to the GUI.
> .
> In real-world development practice, having only "one
> thread talk to the GUI" is nearly universal.  I can't
> think of any good reason to have more.  I'm keeping an
> open mind on this one, though.
>

What about an application server ?

> Along with the categories Andrew listed, there are a few
> other reasons to use threads:
> 1.  Fashion and misinformation....
> 2.  System-level bindings that only give good
>     programmability for threaded APIs.
> 3.  Mildly tangled with the first two, Ben's
>     cases of external stuff that demands thread-
>     level management....
>

So, to sum things up,
1 - one GUI thread is enough and more is definitely bad.
1 - not having system threads running several copies of the interpreter is
not a major hindrance.
2 - having the interpreter run in only one thread eases the implementation
of the GC.
3 - threads are really useful for :
    * coding style (a very personal matter !!)
    * keeping the system responsive under external API calls.

What triggered this discussion is the fact that some calls in the Ruby lib
actually block according to Dave Thomas excellent book.
All the contributions seem to point in the same direction : providing a
simple worker thread wrapper around some of the extension modules should be
more than enough.
My thought was that if the Ruby API could provide a standard easy worker
threading framework for the extensions module to call, it would be nice.
That way, the interpreter could remain untouched.

I'll try to work on that.
Cheers.



In This Thread