On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <bob.news / gmx.net> wrote:
> 
> "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.

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"

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

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