From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-28T22:43:47+09:00
Subject: Re: Ruby Threads...

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

There's a very great deal to the subject of proper multiprocess design, and
Ara's system upthread exemplifies a lot of it, but I'll briefly answer your
points.

Windows: one is sorely tempted to ask why you're considering Windows for a
seriously scalable application, but let's finesse it by noting that
aggregate cost does become a significant factor with scale. So if you have
to use Windows, you're probably trying to meet a political requirement
rather than a technical one ;-).

More to the point, you don't really want to be forking a lot of processes t=
o
run a cooperative multiprocess application. Rather, you want the processes
to be long-running. This does amortize their startup cost (which is large
even on Unix), but far more importantly it gives you an opportunity to avoi=
d
context-switch overhead, which can be extremely expensive on modern
hardware. If your workpile consists of long-running tasks (which it probabl=
y
doesn't), then you don't have to work too hard to get long-running
processes. Otherwise you need an event-driven sytem to keep them busy (and
pinned to their respective processors).

Shared memory: no. Don't do that. Use IPC or network communications. No,
don't do that either. Use a proper event-passing library that wraps all of
that up for you, so your remote-operation activations look like simple
function calls. Remember, you'll want to run your multiprocesses on multipl=
e
machines before you know it. (Avoid distributed objects if possible, becaus=
e
for one thing they force you to couple client and server processes, and for
another you really don't want the management hassles if your network is
asynchronous.)


On 5/27/06, ReggW <me@yourhome.com> wrote:
>
> Francis Cianfrocca wrote:
> > You're making a very interesting point, one I've made many times: you'r=
e
> > saying to write cooperative multiprocess rather than multithreaded
> > programs.
>
> This may work well on Linux, but multiprocesses are very heavy on
> Windows versus multithreads.
>
> > If you take aggregate costs into account (including time-to-market and
> > lifecycle maintenance and support), this approach can be far better tha=
n
> > multithreaded because it's so much more robust and easier to do. Whethe=
r
> > it's as fast, however, is a highly hardware and OS-dependent question.
>
> But with multiprocess you would need to now develope a shared memory
> scheme (MapFiles on Windows) or something similiar if your processes
> need to communicate with each other.
> I would just prefer to have native threads and the
> syncronization/locks/etc available to me to do what I need to do.
>
>
>
>
>
> --
> Posted via http://www.ruby-forum.com/.
>
>

------=_Part_311776_5707150.1148823818811--