"zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
news:a988e9f6040709000063dba1f5 / mail.gmail.com...
> On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <bob.news / gmx.net>
wrote:
> >
> > "zuzu" <sean.zuzu / gmail.com> schrieb im Newsbeitrag
> > news:a988e9f60407081357560a9592 / mail.gmail.com...
> >
> > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <bob.news / gmx.net>
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.

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

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

> > Regards
> >
> >     robert
> >
> >
> > PS: Attached some sample of what I understand from "flow based".
>
> word, i'll give it a serious look this weekend.

Don't look to hard.  I guess it's not overly well designed.  Just to get
the picture.  Basically a processor has an incoming queue which is dealt
with by a thread.  Processing can be anything from printing to sending
something to an attached processor.  Concurrency saftety is ensured be the
queues.  That's about it.

Regards

    robert