"zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
news:a988e9f604070911032a3b0abb / mail.gmail.com...
> On Fri, 9 Jul 2004 23:47:31 +0900, Robert Klemme <bob.news / gmx.net> wrote:
> >
> > "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...
>
> ugh, this sounds bloated already.

No.  It's much easier to have a cetral repository than to try to have each
distributed object register itself which each other.  Of course, if you want
complete failover and redundancy things get more complicated.

> > > > >  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).
>
> hmm...  if you're talking animate and inanimate objects... not really.
>  everything changes.

I see you read your Heraklit.  But independently of the truth of this
statements from a practical point of view it's much more valuable to make
some distinctions.

> > 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.
>
> true.  but i do not think this is over-abstraction.  we probably need
> some real numbers or testing on this though.
>
> > > 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.
>
> i need a better analogy.  you don't just "know" what your car's speed
> is.  your speedometer senses the car's speed (from axel rotation or
> something) and effects a change in needle display.  you sense with
> your eyes detecting light reflecting off the dial of the speedometer,
> and effect change in speed with the gas pedal.  it's always message
> passing.  the speedometer does in fact "speak" its reading to you via
> reflected light.

Well, I guess you can discover message passing in every process if you just
scrutinize it thoroughly enough.

> and again, i find it important that your car will keep moving even if
> your speedometer fails.

Sure.

> how is the programming more complicated if the pattern is consistent?

If String#length is a synchronus call (like it is today), you just invoke it
and have the answer and can work with it.

If it's asynchronous (as in message oriented systems) you have to place your
request in some inbound queue and make sure, you get another event if the
result is there.  Now if the result is sent back with another message you
have to react on it and proceed with whatever calculation you were doing and
that needed the length of the String.

Now, what's more complicated?

> > > > > 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?
>
> exactly what it does now, just not constrained by the unix kernel.  if
> the unix kernel panics, ruby keeps going... and maybe could restart
> the unix kernel.  if ruby panics, it could be restarted from unix.
> and requests for resources between them would be determined by mach.

So basically it's just another way to invoke the interpreter with some
better liveliness guarantees.

    robert