On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <bob.news / gmx.net> wrote:
> 
> "zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
> news:a988e9f60407080151679627fc / mail.gmail.com...
> > ruby, starting the interactive ruby shell, but with filesystem access
> > to unix/bsd through the mach microkernel.  in other words, a "ruby
> > machine" (instead of a "smalltalk machine" or "lisp machine").
> >
> > what do you think?
> 
> Hm, I still don't see the advantages.  As for normal Ruby programs, I
> can't see any.  As for access to kernel functionality, I don't see the
> improvement. I guess it's my lack of understanding, so I would greatly
> appreciate if anyone explains this.
> 
> Kind regards
> 
>     robert

one important aspect i have neglected to emphasize is the nature of
flow-based (aka "agent") programming style in ruby.  see
http://www.jpaulmorrison.com/fbp/index.shtml


ok, here is a very concrete example i am faced with:

# given an apple dual-G5, essentailly four CPU cores are available to
process instructions in parallel.

# i am writing ruby code in the aforementioned style.
think of a beer bottling plant, where bottles move on a conveyor
through various machines:  a washing machine, then a drying machine,
then a filling machine, then a capping machine, then a labeling
machine, then a packaging machine.  each machine does not wait for
"all the bottles" to finish before passing the bottles onto the next
machine.  each machine simply works with the bottles it has when it
has them.
in data-flow programming, the bottles are data which get
modified/transformed by each "machine" which would likely be
singletons or direct class method calls, and the conveyor belt is an
infinite stream but perceived by each "machine" as a bounded buffer.
so the *problem* becomes that several "machines" need to operate on
their buffers at the same time (in parallel).
at the same time, the user requires introspection to keep an eye on
what's happening where, and be able to make dynamic changes to the
data-flow arbitrarily.

# how can ruby utilize the 4 CPU cores for this massively parallel
bounded-buffer data-flow as a single unix process with only internal
threading?

one possible solution i thought of is to port the ruby interpreter as
a Mach microkernel server, sitting beside the bsd "personality"
server.  each object would be a Mach task while each function would be
a Mach thread, and objects would communicate via Mach inter-process
communication (IPC).  networking and filesystems can also be accessed
through Mach.

ruby gets the parallelization it needs, by adopting rather than
writing from scratch, an existing microkernel.  in essence, a "ruby
machine".