From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-28T04:13:01+09:00
Subject: Re: Ruby Threads...

------=_Part_305475_6984351.1148757178569
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

You're making a very interesting point, one I've made many times: you're
saying to write cooperative multiprocess rather than multithreaded programs=
.
If you take aggregate costs into account (including time-to-market and
lifecycle maintenance and support), this approach can be far better than
multithreaded because it's so much more robust and easier to do. Whether
it's as fast, however, is a highly hardware and OS-dependent question. If
you can specify multiprocessor or multicore hardware, multiprocess software
design has a clear edge, IMO. And in a few years nearly all processors for
general computation will be multicore.

(This is a side point (and as we know, the side points always generate the
hottest flames), but I happen to disagree with your choice of DRb. Not
because of the communications model, but because distributed objects are
fundamentally problematic. I'd encourage you to look at multiprocess
event-driven systems. Watch for the upcoming pure-Ruby version of the
eventmachine library on Rubyforge- it will have built-in constructs to
explicitly support multiprocess event-driven programming.)

On 5/27/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>
> On Sat, 27 May 2006, ReggW wrote:
>
> > Francis Cianfrocca wrote:
> >
> >> It seems to me that Ruby's green-thread implementation is perfectly
> >> adequate
> >> for most programmers' requirements.
> >
> > But the problem is that it doesn't take advantage of these new
> multi-core
> > processor that are now starting to become the standard machines being
> sold
> > (at least for my customers).
>
> it's a small problem.  here is some code which starts two processes, thre=
e
> if
> you count the parent.  both run in separate processes using drb as the ip=
c
> layer to make the communication painless.  because the code uses drb the
> com is
> simple.  because it uses multiple processes it allows the kernel to
> migrate
> them to different cpus.  the cost is about 100 lines of pure-ruby (the
> slave
> lib).  notice how easy it is for parent to communicate with child and for
> childrent to communicate with each other:
>
>      harp:~ > cat a.rb
>      require 'slave'
>      require 'yaml'
>
>      class ProcessA
>        def initialize(b) @b =3D b end
>        def process(n) @b.process(n * n) end
>        def pid() Process.pid end
>      end
>
>      class ProcessB
>        def process(n) n + 6 end
>        def pid() Process.pid end
>      end
>
>      b =3D Slave.new(ProcessB.new).object
>      a =3D Slave.new(ProcessA.new(b)).object
>
>      y 'a.pid' =3D> a.pid
>      y 'b.pid' =3D> b.pid
>
>      y 'answer' =3D> a.process(6)
>
>
>      harp:~ > ruby a.rb
>      ---
>      a.pid: 15142
>      ---
>      b.pid: 15141
>      ---
>      answer: 42
>
>
> this is one of those things that allows one to consider designs that woul=
d
> be
> untenable in other languages.  obviously using this approach it would be
> trivial to setup a job that spawned 16 intercommunicating proccess,
> something
> which would be absurd to code in c.
>
> regards.
>
>
> -a
> --
> be kind whenever possible... it is always possible.
> - h.h. the 14th dali lama
>
>

------=_Part_305475_6984351.1148757178569--