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.

> > > >  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.

> 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.

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

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

> > > > 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.

>     robert
> 
> 

-z