ruby interpreter as mach kernel server (beside bsd)

Discussion in 'Ruby' started by zuzu, Jul 8, 2004.

  1. zuzu

    zuzu Guest

    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?


    7/7/2004 11:37 PM
    http://www.jpaulmorrison.com/cgi-bin/wiki.pl?PushingTheEnvelope

    so... in trying to solve the "ruby space" problem, i've been thought
    experimenting with the what-if of the ruby interpreter / runtime
    environment as a kernel server in parallel to a unix "personality"
    server under the mach microkernel.

    unlike the design of GNU/hurd, most microkernel unix operating systems
    implement Mach for the basics (multi-tasking/processes, threads,
    multi-processor on single machine or over a network, inter-process
    communication / IPC, memory protection) and then a single "unix kernel
    server" to fill out the rest of the unix functionality found in
    monolithic kernels such as linux.

    so if the ruby interpreter were another "kernel server" parallel to
    the "unix kernel server", ruby would still interact with the
    traditional unix environment, but each object in "ruby space" could be
    its own process (as compiled C utilities are in traditional unix) for
    truely reuseable and fault-resistent components. (this essentially
    creates a virtual "ruby machine" not unlike "smalltalk machines" and
    "lisp machines" of yore.)

    the reason i mention such a wild idea here, other than continuing the
    discourse on threads and processes, is because of how similar the Mach
    design feels compared to flow-based programming FBP:

    1. object-based APIs with communication channels (for example,
    *ports*) as object references
    2. highly parallel execution, including preemptively scheduled threads
    and support for SMP
    3. a flexible scheduling framework, with support for real-time usage
    4. a complete set of IPC primitives, including messaging, RPC,
    (a)synchronization, and notification
    5. support for large virtual address spaces, shared memory regions,
    and memory objects backed by persistent store
    6. proven extensibility and portability, for example across
    instruction set architectures and in distributed environments
    7. security and resource management as a fundamental principle of
    design; all resources are virtualized

    http://developer.apple.com/document...rnelProgramming/Mach/chapter_6_section_1.html

    it's almost as if the Mach kernel just needs a friendly interface to
    running code through it, and ruby could very well be that friendly
    syntactic sugar.

    of course this grossly underestimates the difficulty of writing kernel
    software, particularly for a microkernel such as Mach. paul, your
    expertise seems very C heavy, perhaps you have a better gague of
    approachability.


    7/8/2004 12:26 AM
    http://developer.apple.com/document...rnelProgramming/Mach/chapter_6_section_3.html

    A thread

    * is a point of control flow in a task.
    * has access to all of the elements of the containing task.
    * executes (potentially) in parallel with other threads, even threads
    within the same task.
    * has minimal state information for low overhead.

    A task

    * is a collection of system resources. These resources, with the
    exception of the address space, are referenced by ports. These
    resources may be shared with other tasks if rights to the ports are so
    distributed.
    * provides a large, potentially sparse address space, referenced by
    virtual address. Portions of this space may be shared through
    inheritance or external memory management.
    * contains some number of threads.

    Note that a task has no life of its own—only threads execute
    instructions. When it is said that "task Y does X," what is really
    meant is that "a thread contained within task Y does X."


    to me, this sounds as though in ruby, a task would map to an object,
    and a thread to a function.
     
    zuzu, Jul 8, 2004
    #1
    1. Advertising

  2. "zuzu" <> schrieb im Newsbeitrag
    news:...
    > 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
     
    Robert Klemme, Jul 8, 2004
    #2
    1. Advertising

  3. il Thu, 8 Jul 2004 17:51:36 +0900, zuzu <> ha
    scritto::

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


    I'll use L4::pistachio wich should have become stable as of now.
    I believe the guys from the Io language had the interpreter running
    directly on L4, wich is a wonderful microkernel (give my little
    understanding of OS theory, anyway)
     
    gabriele renzi, Jul 8, 2004
    #3
  4. zuzu

    zuzu Guest

    On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    > > 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".
     
    zuzu, Jul 8, 2004
    #4
  5. zuzu

    zuzu Guest

    zuzu, Jul 8, 2004
    #5
  6. "zuzu" <> schrieb im Newsbeitrag
    news:...

    > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <> 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.

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

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

    Regards

    robert


    PS: Attached some sample of what I understand from "flow based".
     
    Robert Klemme, Jul 9, 2004
    #6
  7. zuzu

    zuzu Guest

    On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    >
    > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <> 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.

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

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

    > Regards
    >
    > robert
    >
    >
    > PS: Attached some sample of what I understand from "flow based".


    word, i'll give it a serious look this weekend.

    -z
     
    zuzu, Jul 9, 2004
    #7
  8. "zuzu" <> schrieb im Newsbeitrag
    news:...
    > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <>

    wrote:
    > >
    > > "zuzu" <> schrieb im Newsbeitrag
    > > news:...
    > >
    > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <>

    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
     
    Robert Klemme, Jul 9, 2004
    #8
  9. zuzu

    zuzu Guest

    On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    > > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <>

    > wrote:
    > > >
    > > > "zuzu" <> schrieb im Newsbeitrag
    > > > news:...
    > > >
    > > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme <>

    > 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
    >
    >
     
    zuzu, Jul 9, 2004
    #10
  10. "zuzu" <> schrieb im Newsbeitrag
    news:...
    > On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <>

    wrote:
    > >
    > > "zuzu" <> schrieb im Newsbeitrag
    > > news:...
    > > > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <>

    > > wrote:
    > > > >
    > > > > "zuzu" <> schrieb im Newsbeitrag
    > > > > news:...
    > > > >
    > > > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme

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

    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?

    robert
     
    Robert Klemme, Jul 9, 2004
    #11
  11. zuzu

    zuzu Guest

    On Fri, 9 Jul 2004 17:32:33 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    > > On Fri, 9 Jul 2004 16:27:32 +0900, Robert Klemme <>

    > wrote:
    > > >
    > > > "zuzu" <> schrieb im Newsbeitrag
    > > > news:...
    > > > > On Fri, 9 Jul 2004 14:57:33 +0900, Robert Klemme <>
    > > > wrote:
    > > > > >
    > > > > > "zuzu" <> schrieb im Newsbeitrag
    > > > > > news:...
    > > > > >
    > > > > > > On Thu, 8 Jul 2004 19:27:41 +0900, Robert Klemme

    > <>
    > > > 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
     
    zuzu, Jul 9, 2004
    #12
  12. "zuzu" <> schrieb im Newsbeitrag
    news:...

    <snip/>

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


    There's DRB. And you have plain sockets. So you can do that with Ruby
    today already.

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


    I'm not sure what exactly you mean by "data is active". It's basic OO
    that each object has methods that it can respond to. Activitiy as own
    thread of control is a different story. But that is not build into Ruby.
    You can implement it in Ruby as I've tried to show.

    > a String might announce its .length or get .reverse'd or .chomp'd.


    But only when asked. And constructing an event mechanism around the call
    to #length is ridiculous.

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


    The point being?

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


    LOL

    robert
     
    Robert Klemme, Jul 9, 2004
    #13
  13. zuzu

    zuzu Guest

    On Fri, 9 Jul 2004 20:12:31 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    >
    > <snip/>
    >
    > > > 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.

    >
    > There's DRB. And you have plain sockets. So you can do that with Ruby
    > today already.


    i think i've touched on this already as well...

    dRuby is cool. (the FBP wiki analyzes linda, btw.) however, my
    current understanding is that any one instance of ruby will not
    introspect across all available instances of ruby, only itself. this
    makes tracking of all accessible ruby objects within any ruby instance
    difficult. i suppose introspection could be extended to introspect
    across dRuby ports... or maybe i'm plain wrong about this. anyone
    here a dRuby expert?

    i will almost certainly need to work within such a framework for the
    short-term anyway.

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

    >
    > I'm not sure what exactly you mean by "data is active". It's basic OO
    > that each object has methods that it can respond to. Activitiy as own
    > thread of control is a different story. But that is not build into Ruby.
    > You can implement it in Ruby as I've tried to show.
    >
    > > a String might announce its .length or get .reverse'd or .chomp'd.

    >
    > But only when asked. And constructing an event mechanism around the call
    > to #length is ridiculous.


    silly perhaps, but:
    1.) why create an exceptional circumstance for data? again, with O(1)
    schedulers extra processes won't suck performance, and keeping data
    protected separately increases robustness.
    2.) http://c2.com/cgi/wiki?LazyProgrammer or using a thread for data
    instead of a process seems like premature optimization, and breaks the
    rule from hagakure of "making two things out of one".

    basically, do the reasons for adding threads into the mix outweigh the
    cost of having to think about them rather than just processes/IPC?

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

    >
    > The point being?


    ...that just because the html renderer in firefox shits a brick is no
    reason why i should lose writing this unfinished email. the faulty
    object should be replaced like a lightbulb, without turning off all
    the electricity in the apartment. (the computer in this analogy being
    the entire building, and the internet the city.)

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

    >
    > LOL
    >
    > robert
    >
    >


    -z
     
    zuzu, Jul 9, 2004
    #14
  14. "zuzu" <> schrieb im Newsbeitrag
    news:...
    > On Fri, 9 Jul 2004 20:12:31 +0900, Robert Klemme <>

    wrote:
    > >
    > > "zuzu" <> schrieb im Newsbeitrag
    > > news:...
    > >
    > > <snip/>
    > >
    > > > > 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.

    > >
    > > There's DRB. And you have plain sockets. So you can do that with

    Ruby
    > > today already.

    >
    > i think i've touched on this already as well...
    >
    > dRuby is cool. (the FBP wiki analyzes linda, btw.) however, my
    > current understanding is that any one instance of ruby will not
    > introspect across all available instances of ruby, only itself. this
    > makes tracking of all accessible ruby objects within any ruby instance
    > difficult. i suppose introspection could be extended to introspect
    > across dRuby ports... or maybe i'm plain wrong about this. anyone
    > here a dRuby expert?


    Not too much of an expert, but this won't work automatically. When
    working with multiple DRB servers (= processes) you'd certainly have a
    single instance as a repository where all others register themselv.
    Typically this is implemented as a naming service. You could as well use
    LDAP or similar for this...

    > > > a String might announce its .length or get .reverse'd or .chomp'd.

    > >
    > > But only when asked. And constructing an event mechanism around the

    call
    > > to #length is ridiculous.

    >
    > silly perhaps, but:
    > 1.) why create an exceptional circumstance for data? again, with O(1)
    > schedulers extra processes won't suck performance, and keeping data
    > protected separately increases robustness.


    With all architectures I know the overhead is simply too big. This would
    not yield reasonable performance. And it's the wrong abstraction IMHO.
    In the real world(TM) we have a differentiation between actors / subjects
    (humans, animals, maybe even machines) and objects (passive things). It's
    not always good to make one thing from two things - especially if they are
    not very similar. Software engineering is not about finding minimal or
    maxmial abstractions but to find appropriate abstractions.

    > 2.) http://c2.com/cgi/wiki?LazyProgrammer or using a thread for data
    > instead of a process seems like premature optimization, and breaks the
    > rule from hagakure of "making two things out of one".
    >
    > basically, do the reasons for adding threads into the mix outweigh the
    > cost of having to think about them rather than just processes/IPC?


    I'd say things get more complicated if you make everything active. If you
    want to know how fast your car runs at the momemt you look at the
    speedometer and get the answer immediately. You don't send a request to
    the car which in turn answers with a voice message that indicates current
    speed.

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

    > >
    > > The point being?

    >
    > ..that just because the html renderer in firefox shits a brick is no
    > reason why i should lose writing this unfinished email. the faulty
    > object should be replaced like a lightbulb, without turning off all
    > the electricity in the apartment. (the computer in this analogy being
    > the entire building, and the internet the city.)


    I get the feeling we're talking past each other. Care to explain the
    concept of "ruby interpreter as mach kernel server"? How does it work?
    What does it do?

    robert
     
    Robert Klemme, Jul 9, 2004
    #15
  15. zuzu

    zuzu Guest

    On Fri, 9 Jul 2004 23:47:31 +0900, Robert Klemme <> wrote:
    >
    > "zuzu" <> schrieb im Newsbeitrag
    > news:...
    > > On Fri, 9 Jul 2004 20:12:31 +0900, Robert Klemme <>

    > wrote:
    > > >
    > > > "zuzu" <> schrieb im Newsbeitrag
    > > > news:...
    > > >
    > > > <snip/>
    > > >
    > > > > > 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.
    > > >
    > > > There's DRB. And you have plain sockets. So you can do that with

    > Ruby
    > > > today already.

    > >
    > > i think i've touched on this already as well...
    > >
    > > dRuby is cool. (the FBP wiki analyzes linda, btw.) however, my
    > > current understanding is that any one instance of ruby will not
    > > introspect across all available instances of ruby, only itself. this
    > > makes tracking of all accessible ruby objects within any ruby instance
    > > difficult. i suppose introspection could be extended to introspect
    > > across dRuby ports... or maybe i'm plain wrong about this. anyone
    > > here a dRuby expert?

    >
    > Not too much of an expert, but this won't work automatically. When
    > working with multiple DRB servers (= processes) you'd certainly have a
    > single instance as a repository where all others register themselv.
    > Typically this is implemented as a naming service. You could as well use
    > LDAP or similar for this...


    ugh, this sounds bloated already.

    > > > > a String might announce its .length or get .reverse'd or .chomp'd.
    > > >
    > > > But only when asked. And constructing an event mechanism around the

    > call
    > > > to #length is ridiculous.

    > >
    > > silly perhaps, but:
    > > 1.) why create an exceptional circumstance for data? again, with O(1)
    > > schedulers extra processes won't suck performance, and keeping data
    > > protected separately increases robustness.

    >
    > With all architectures I know the overhead is simply too big. This would
    > not yield reasonable performance. And it's the wrong abstraction IMHO.
    > In the real world(TM) we have a differentiation between actors / subjects
    > (humans, animals, maybe even machines) and objects (passive things).


    hmm... if you're talking animate and inanimate objects... not really.
    everything changes.

    > It's
    > not always good to make one thing from two things - especially if they are
    > not very similar. Software engineering is not about finding minimal or
    > maxmial abstractions but to find appropriate abstractions.


    true. but i do not think this is over-abstraction. we probably need
    some real numbers or testing on this though.

    > > 2.) http://c2.com/cgi/wiki?LazyProgrammer or using a thread for data
    > > instead of a process seems like premature optimization, and breaks the
    > > rule from hagakure of "making two things out of one".
    > >
    > > basically, do the reasons for adding threads into the mix outweigh the
    > > cost of having to think about them rather than just processes/IPC?

    >
    > I'd say things get more complicated if you make everything active. If you
    > want to know how fast your car runs at the momemt you look at the
    > speedometer and get the answer immediately. You don't send a request to
    > the car which in turn answers with a voice message that indicates current
    > speed.


    i need a better analogy. you don't just "know" what your car's speed
    is. your speedometer senses the car's speed (from axel rotation or
    something) and effects a change in needle display. you sense with
    your eyes detecting light reflecting off the dial of the speedometer,
    and effect change in speed with the gas pedal. it's always message
    passing. the speedometer does in fact "speak" its reading to you via
    reflected light.

    and again, i find it important that your car will keep moving even if
    your speedometer fails.

    how is the programming more complicated if the pattern is consistent?

    > > > > 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.
    > > >
    > > > The point being?

    > >
    > > ..that just because the html renderer in firefox shits a brick is no
    > > reason why i should lose writing this unfinished email. the faulty
    > > object should be replaced like a lightbulb, without turning off all
    > > the electricity in the apartment. (the computer in this analogy being
    > > the entire building, and the internet the city.)

    >
    > I get the feeling we're talking past each other. Care to explain the
    > concept of "ruby interpreter as mach kernel server"? How does it work?
    > What does it do?


    exactly what it does now, just not constrained by the unix kernel. if
    the unix kernel panics, ruby keeps going... and maybe could restart
    the unix kernel. if ruby panics, it could be restarted from unix.
    and requests for resources between them would be determined by mach.

    > robert
    >
    >


    -z
     
    zuzu, Jul 9, 2004
    #16
  16. zuzu

    Richard Dale Guest

    zuzu wrote:

    > On Thu, 8 Jul 2004 16:57:24 -0400, zuzu <> 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

    >
    > oops, i meant "actor"; classic mistake. http://cliki.tunes.org/Actor
    > http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion

    That's interesting - I've just implemented a ruby version of DCOP for the
    KDE Korundom bindings. DCOP is the equivalent of Cocoa Distributed Objects,
    rather than Mach tasks/ipc which is much lower level. It occured to me how
    you could build an actor-like system in ruby DCOP to schedule workflow in
    C++ apps. All KDE apps have interfaces exposed as DCOP, which gives you
    cross process introspection, and nice easy to use cross language rpc.

    You used to write 'Mach Interface Generator' files like xdr to describe the
    marshalling (is it still the same?), so for ruby you would do that
    dynamically. But if you're only communicating with other ruby apps that can
    understand your protocol, it seems a bit limiting. Does RubyCocoa implement
    Distributed Objects? That seems a better place to start on Mac OS X to me.

    In Korundum, you define DCOP slots like this:

    class MyWidget < KDE::pushButton
    k_dcop 'void mySlot(QString)', 'QPoint getPoint(QString)'

    def initialize(parent, name)
    super
    end

    def mySlot(greeting)
    puts "greeting: #{greeting}"
    end

    def getPoint(msg)
    puts "message: #{msg}"
    return Qt::point.new(50, 100)
    end
    end

    The 'tag' or unique name for this actor is 'dcopslot/MyWidget/<slotname>' -
    the name of the app and the class with the slot.

    Here is an example of synchronous communication ('slots' are Qt's in process
    equivalent of DCOP slots):

    class SenderWidget < PushButton
    def initialize(parent, name)
    super
    connect(self, SIGNAL('clicked()'), self, SLOT('doit()'))
    end

    slots 'doit()'

    def doit()
    dcopRef = DCOPRef.new("dcopslot", "MyWidget")
    result = dcopRef.call("QPoint getPoint(QString)", "Hello from
    dcopcall")
    puts "result class: #{result.class.name} x: #{result.x} y:
    #{result.y}"
    end
    end

    Of course in ruby the above call() should really look like this, and use
    method_missing():

    result = dcopRef.getPoint("Hello from dcopcall")

    Or synchronous communication:

    class SenderWidget < KDE::pushButton
    def initialize(parent, name)
    super
    Qt::Object::connect(self, SIGNAL('clicked()'), self, SLOT('doit()'))
    end

    slots 'doit()'

    def doit()
    dcopRef = KDE::DCOPRef.new("dcopslot", "MyWidget")
    dcopRef.send("mySlot(QString)", "Hello from dcopsend")
    end
    end

    And of course you can send DCOPRef's over DCOP to other KDE programs or
    actors.

    The script for the actor's behaviour definition can be just a ruby string
    instance variable, which is eval'd for the current request in the actor's
    'become' method. Each response to a message generates the script to respond
    to the next message.

    So the next step is to try and write the factorial example from Gul Agha
    Actors book in DCOP..

    -- Richard
     
    Richard Dale, Jul 10, 2004
    #17
  17. "zuzu" <> schrieb im Newsbeitrag
    news:...
    > On Fri, 9 Jul 2004 23:47:31 +0900, Robert Klemme <> wrote:
    > >
    > > "zuzu" <> schrieb im Newsbeitrag
    > > news:...
    > > > On Fri, 9 Jul 2004 20:12:31 +0900, Robert Klemme <>

    > > wrote:
    > > > >
    > > > > "zuzu" <> schrieb im Newsbeitrag
    > > > > news:...
    > > > >
    > > > > <snip/>
    > > > >
    > > > > > > 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.
    > > > >
    > > > > There's DRB. And you have plain sockets. So you can do that with

    > > Ruby
    > > > > today already.
    > > >
    > > > i think i've touched on this already as well...
    > > >
    > > > dRuby is cool. (the FBP wiki analyzes linda, btw.) however, my
    > > > current understanding is that any one instance of ruby will not
    > > > introspect across all available instances of ruby, only itself. this
    > > > makes tracking of all accessible ruby objects within any ruby instance
    > > > difficult. i suppose introspection could be extended to introspect
    > > > across dRuby ports... or maybe i'm plain wrong about this. anyone
    > > > here a dRuby expert?

    > >
    > > Not too much of an expert, but this won't work automatically. When
    > > working with multiple DRB servers (= processes) you'd certainly have a
    > > single instance as a repository where all others register themselv.
    > > Typically this is implemented as a naming service. You could as well

    use
    > > LDAP or similar for this...

    >
    > ugh, this sounds bloated already.


    No. It's much easier to have a cetral repository than to try to have each
    distributed object register itself which each other. Of course, if you want
    complete failover and redundancy things get more complicated.

    > > > > > a String might announce its .length or get .reverse'd or

    ..chomp'd.
    > > > >
    > > > > But only when asked. And constructing an event mechanism around the

    > > call
    > > > > to #length is ridiculous.
    > > >
    > > > silly perhaps, but:
    > > > 1.) why create an exceptional circumstance for data? again, with O(1)
    > > > schedulers extra processes won't suck performance, and keeping data
    > > > protected separately increases robustness.

    > >
    > > With all architectures I know the overhead is simply too big. This

    would
    > > not yield reasonable performance. And it's the wrong abstraction IMHO.
    > > In the real world(TM) we have a differentiation between actors /

    subjects
    > > (humans, animals, maybe even machines) and objects (passive things).

    >
    > hmm... if you're talking animate and inanimate objects... not really.
    > everything changes.


    I see you read your Heraklit. But independently of the truth of this
    statements from a practical point of view it's much more valuable to make
    some distinctions.

    > > It's
    > > not always good to make one thing from two things - especially if they

    are
    > > not very similar. Software engineering is not about finding minimal or
    > > maxmial abstractions but to find appropriate abstractions.

    >
    > true. but i do not think this is over-abstraction. we probably need
    > some real numbers or testing on this though.
    >
    > > > 2.) http://c2.com/cgi/wiki?LazyProgrammer or using a thread for data
    > > > instead of a process seems like premature optimization, and breaks the
    > > > rule from hagakure of "making two things out of one".
    > > >
    > > > basically, do the reasons for adding threads into the mix outweigh the
    > > > cost of having to think about them rather than just processes/IPC?

    > >
    > > I'd say things get more complicated if you make everything active. If

    you
    > > want to know how fast your car runs at the momemt you look at the
    > > speedometer and get the answer immediately. You don't send a request to
    > > the car which in turn answers with a voice message that indicates

    current
    > > speed.

    >
    > i need a better analogy. you don't just "know" what your car's speed
    > is. your speedometer senses the car's speed (from axel rotation or
    > something) and effects a change in needle display. you sense with
    > your eyes detecting light reflecting off the dial of the speedometer,
    > and effect change in speed with the gas pedal. it's always message
    > passing. the speedometer does in fact "speak" its reading to you via
    > reflected light.


    Well, I guess you can discover message passing in every process if you just
    scrutinize it thoroughly enough.

    > and again, i find it important that your car will keep moving even if
    > your speedometer fails.


    Sure.

    > how is the programming more complicated if the pattern is consistent?


    If String#length is a synchronus call (like it is today), you just invoke it
    and have the answer and can work with it.

    If it's asynchronous (as in message oriented systems) you have to place your
    request in some inbound queue and make sure, you get another event if the
    result is there. Now if the result is sent back with another message you
    have to react on it and proceed with whatever calculation you were doing and
    that needed the length of the String.

    Now, what's more complicated?

    > > > > > 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.
    > > > >
    > > > > The point being?
    > > >
    > > > ..that just because the html renderer in firefox shits a brick is no
    > > > reason why i should lose writing this unfinished email. the faulty
    > > > object should be replaced like a lightbulb, without turning off all
    > > > the electricity in the apartment. (the computer in this analogy being
    > > > the entire building, and the internet the city.)

    > >
    > > I get the feeling we're talking past each other. Care to explain the
    > > concept of "ruby interpreter as mach kernel server"? How does it work?
    > > What does it do?

    >
    > exactly what it does now, just not constrained by the unix kernel. if
    > the unix kernel panics, ruby keeps going... and maybe could restart
    > the unix kernel. if ruby panics, it could be restarted from unix.
    > and requests for resources between them would be determined by mach.


    So basically it's just another way to invoke the interpreter with some
    better liveliness guarantees.

    robert
     
    Robert Klemme, Jul 11, 2004
    #18
  18. Robert Klemme <> wrote:

    > If String#length is a synchronus call (like it is today), you just invoke it
    > and have the answer and can work with it.
    >
    > If it's asynchronous (as in message oriented systems) you have to place your
    > request in some inbound queue and make sure, you get another event if the
    > result is there. Now if the result is sent back with another message you
    > have to react on it and proceed with whatever calculation you were doing and
    > that needed the length of the String.
    >
    > Now, what's more complicated?


    This might mesh well with Oz's dataflow concurrency, where the thread
    would essentially suspend itself until the value was available.

    martin
     
    Martin DeMello, Jul 12, 2004
    #19
  19. il Mon, 12 Jul 2004 12:12:04 GMT, Martin DeMello
    <> ha scritto::

    >Robert Klemme <> wrote:
    >
    >> If String#length is a synchronus call (like it is today), you just invoke it
    >> and have the answer and can work with it.
    >>
    >> If it's asynchronous (as in message oriented systems) you have to place your
    >> request in some inbound queue and make sure, you get another event if the
    >> result is there. Now if the result is sent back with another message you
    >> have to react on it and proceed with whatever calculation you were doing and
    >> that needed the length of the String.
    >>
    >> Now, what's more complicated?

    >
    >This might mesh well with Oz's dataflow concurrency, where the thread
    >would essentially suspend itself until the value was available.


    I think this maps quite good to the actor model in Io
    (www.iolanguage.com).
    In Io you call a method like:

    obj methodname(args)

    and if you call it like:
    obj @methodname(args)

    it returns you a Future object.
    You then test the future object and in case you retriev the value:
    future_object isReady
    future_object value print

    Otherwise you can avoid to handle the future object like this:
    obj @@methodname(args) #returns nil

    It is an interesting model, and imho seem very OO, simple and
    powerful.

    Now if I just was good enough to implement Object#async_send() ... ;)

    PS
    I may be wrong about the syntax, not really an Io programmer
     
    gabriele renzi, Jul 12, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    390
  2. yogesh
    Replies:
    3
    Views:
    595
    Kenny McCormack
    Feb 12, 2006
  3. Homer
    Replies:
    2
    Views:
    16,589
    Homer
    Aug 13, 2007
  4. Replies:
    3
    Views:
    179
  5. Lars Gierth
    Replies:
    6
    Views:
    233
    David Masover
    Mar 20, 2010
Loading...

Share This Page