"zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
news:a988e9f604070904465c9eab78 / mail.gmail.com...
> On Fri, 9 Jul 2004 20:12:31 +0900, Robert Klemme <bob.news / gmx.net>
wrote:
> >
> > "zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
> > news:a988e9f6040709021854586eb0 / mail.gmail.com...
> >
> > <snip/>
> >
> > > > The usual tradeoff is, that threads are cheaper (some OS call them
> > Leight
> > > > Weight Processes) because there's less overhead involved during
task
> > > > switches.  Threads automatically share all their memory while for
> > > > processes you have to implement that using the operating system's
> > > > mechanisms for shared mem - or message passing.  Whatever.
> > >
> > > word.  and appearantly in 20% of situations, relying on the OS (or
> > > microkernel) to pass messages between processes/tasks works while
> > > threading crashes, probably because of a goof sharing that memory.
> > > with today's inexpensive hardware, 90% hardware in the field can
> > > handle the penalty of the "heavier" processes/tasks to gain an
> > > increase in human creativity resource productivity.
> > >
> > > so if we dismiss threads, either ruby has to be able to talk to its
> > > unix host for its own processes, or it's going to talk to the kernel
> > > for that.  i'm not sure, but i think this amounts to the same thing,
> > > which is how i arrived at this original topic to begin with.
> >
> > There's DRB.  And you have plain sockets.  So you can do that with
Ruby
> > today already.
>
> i think i've touched on this already as well...
>
> dRuby is cool.  (the FBP wiki analyzes linda, btw.)  however, my
> current understanding is that any one instance of ruby will not
> introspect across all available instances of ruby, only itself.  this
> makes tracking of all accessible ruby objects within any ruby instance
> difficult.  i suppose introspection could be extended to introspect
> across dRuby ports...  or maybe i'm plain wrong about this.  anyone
> here a dRuby expert?

Not too much of an expert, but this won't work automatically.  When
working with multiple DRB servers (= processes) you'd certainly have a
single instance as a repository where all others register themselv.
Typically this is implemented as a naming service.  You could as well use
LDAP or similar for this...

> > >  a String might announce its .length or get .reverse'd or .chomp'd.
> >
> > But only when asked.  And constructing an event mechanism around the
call
> > to #length is ridiculous.
>
> silly perhaps, but:
> 1.) why create an exceptional circumstance for data?  again, with O(1)
> schedulers extra processes won't suck performance, and keeping data
> protected separately increases robustness.

With all architectures I know the overhead is simply too big.  This would
not yield reasonable performance.  And it's the wrong abstraction IMHO.
In the real world(TM) we have a differentiation between actors / subjects
(humans, animals, maybe even machines) and objects (passive things).  It's
not always good to make one thing from two things - especially if they are
not very similar.  Software engineering is not about finding minimal or
maxmial abstractions but to find appropriate abstractions.

> 2.) http://c2.com/cgi/wiki?LazyProgrammer or using a thread for data
> instead of a process seems like premature optimization, and breaks the
> rule from hagakure of "making two things out of one".
>
> basically, do the reasons for adding threads into the mix outweigh the
> cost of having to think about them rather than just processes/IPC?

I'd say things get more complicated if you make everything active.  If you
want to know how fast your car runs at the momemt you look at the
speedometer and get the answer immediately.  You don't send a request to
the car which in turn answers with a voice message that indicates current
speed.

> > > more importantly, when the machine filling a bottle dies, i don't
want
> > > the repairmen to haul away the bottle with the broken machine.  i
want
> > > them to take the bottle out, install the new machine, and put that
> > > bottle back in the new machine.
> >
> > The point being?
>
> ..that just because the html renderer in firefox shits a brick is no
> reason why i should lose writing this unfinished email.  the faulty
> object should be replaced like a lightbulb, without turning off all
> the electricity in the apartment.  (the computer in this analogy being
> the entire building, and the internet the city.)

I get the feeling we're talking past each other.  Care to explain the
concept of "ruby interpreter as mach kernel server"?  How does it work?
What does it do?

    robert