Re: ruby interpreter as mach kernel server (beside bsd)

On Fri, 9 Jul 2004 17:32:33 +0900, Robert Klemme <[e-mail]> wrote:
> 
> "zuzu" <[e-mail]> schrieb im Newsbeitrag
> news:[e-mail]...
> > On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <[e-mail]>
> wrote:
> > >
> > > "zuzu" <[e-mail]> schrieb im Newsbeitrag
> > > news:[e-mail]...
> > > > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <[e-mail]>
> > > wrote:
> > > > >
> > > > > "zuzu" <[e-mail]> schrieb im Newsbeitrag
> > > > > news:[e-mail]...
> > > > >
> > > > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme
> <[e-mail]>
> > > wrote:
> > > > >
> > > > > > 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
> > > > >
> > > > > "Flow based" seems to me just another name for "event driven" from
> > > what I
> > > > > read so far.  It's a bit graph theory, a bit Petri Nets, a bit
> > > concurrency
> > > > > theory - not nearly as sensational as the author tries to make us
> > > think.
> > > >
> > > > word on graph & concurrency theory, reading up on petri nets now
> > > > (wikipedia)...  (also reminds me to finish reading 'Linked' by ALB.)
> > >
> > > :-))
> > >
> > > > perhaps there's something better for me to read up on event driven
> > > > programming besides [http://c2.com/cgi/wiki?EventDrivenProgramming],
> > > > but it sounds much earlier in the evolution of an idea.
> > >
> > > I think in the telco world this is quite ubiquituous.  SDL is used to
> > > design such scenarions (communicating proceses) and SDL is widely used
> in
> > > that area AFAIK.
> >
> > word, i think i've heard that before.  if i think of the specific
> > context i'll post it.
> >
> > > > > > # 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?
> > > > >
> > > > > So basically what you want is, that Ruby makes use of native
> threads.
> > > I
> > > > > guess it would be much easier to implement a Ruby interpreter that
> > > uses
> > > > > native threads than to make a Mach microkernel server.  And it's
> more
> > > > > portable (i.e. POSIX threads).  This sounds a bit like the wrong
> > > hammer to
> > > > > your problem.  But then again, I'm not a microkernel expert.
> > > >
> > > > maybe i'm nitpicking, but i feel a problem exists that processes,
> not
> > > > threads, are necessary.  when the parent process dies (perhaps
> because
> > > > of a bad thread), all of its threads go with it.  this is a problem
> > > > when one small error causes my entire application to crash.  (one
> > > > small error in one object in my web browser should not lose me all
> of
> > > > my "unsaved" rendered pages and URL information with it.  just that
> > > > one faulty object should die and get respawned.)  maintaining my
> human
> > > > productivity with persistent objects is more valuable than the
> > > > footprint of many processes.  O(1) schedulers make "too many
> > > > processes" a moot point in a cheap hardware world anyway, methinks.
> > >
> > > Well, normally a dying Ruby thread does not kill the whole process.
> > > Whether multiple processes or threads is not the major point.  The
> major
> > > point is that you need concurrency for flow based programs to happen,
> not
> > > a kernel integration.  The kernel integration might be a means but it
> > > looks inappropriate to me.
> >
> > but processes never corrupt/crash other processes, except in the event
> > of a kernel panic, correct?  however much debate exists over the
> > safety of threads.  though pan-unix compatability would be much more
> > popular than a mach kernel implementation (which basically means apple
> > xnu and gnu/hurd).
> >
> > http://c2.com/cgi/wiki?ThreadsConsideredHarmful
> >
> > " Some tasks may be truly independent; having independent simultaneous
> > flows of control is useful.
> >     * But: Separate processes may be a better solution.
> >           o On some OS's (ie Windows) that is much more expensive than
> > separate threads (on Unix derivatives, separate processes are much
> > cheaper)"
> >
> > and according to john carmack writing quake 3:
> > #  avoid threads if possible
> > # if you have to have threads, then have only one per CPU
> > # avoid threads if possible
> > # share as little data as possible between threads
> > # are you sure a separate process with shared memory or other IPC
> wouldn't do?
> >
> > i think inter-process communication (IPC) is more preferable as well.
> > (though i'm open to discussing the semantical differences.)
> >
> > i believe i am asking this same question:
> > "I would reply to GlenStampoultzis with a question of my own: why use
> > threads at all if you isolate the parts of your program properly?
> > Processes with message passing could do just as well, no?  --
> > PierrePhaneuf"
> 
> 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.

> When I said "The major point is that you need concurrency for flow based
> programs to happen, not a kernel integration." I wanted to make clear that
> you don't need kernel integration to make flow base software happen in
> Ruby in the first place.  It's the concurrency and especially utilization
> of several CPU's which can't happen with the current interpreter.  (Hence
> Ruby2 - AFAIK native threads is a planned feature there.)
> 
> > > > > > 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.
> > > > >
> > > > > IMHO making each object a mach task would be overkill.  You
> probably
> > > meant
> > > > > each *component* (i.e. independent self contained processing unit
> as
> > > > > described by Paul Morrison) should be a mach task.
> > > >
> > > > you do not think that paul's "components" essentially map directly
> to
> > > > ruby "objects"?
> > >
> > > Exactly.
> >
> > hehe, um, because...?
> 
> 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.
 a String might announce its .length or get .reverse'd or .chomp'd.

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.

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

>     robert
> 
> 

-z