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