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?

i will almost certainly need to work within such a framework for the
short-term anyway.

> > > It doesn't make sense.  Not every instance does processing, just like
> the
> > > bottles are shoved around only but without any activity on their own.
> You
> > > don't want a String to have a thread of control.  What should it do?
> >
> > now that i'm answering the question, i may not have been considering
> > the inheritence model in ruby (if that's the reality of the
> > interpreter)... but my thought process was:  even data in ruby is
> > active, and i think this is a positive consequence of data-as-objects.
> 
> I'm not sure what exactly you mean by "data is active".  It's basic OO
> that each object has methods that it can respond to.  Activitiy as own
> thread of control is a different story.  But that is not build into Ruby.
> You can implement it in Ruby as I've tried to show.
> 
> >  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.
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?

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

> > if a bottle breaks, well so it goes.  but i feel the computer can work
> > harder to not throw the baby out with the bath water, rather than
> > making me create a new baby.  (as fun as that may be!)
> 
> LOL
> 
>     robert
> 
> 

-z