<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 16-07-05 01:31 PM, David McClain
      wrote:<br>
    </div>
    <blockquote
      cite="mid:216A2ADF-9067-4E54-B3F0-A9810562B38C@refined-audiometrics.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Hi Paul,
      <div class=""><br class="">
      </div>
      <div class="">Please forgive my ignorance, </div>
    </blockquote>
    <br>
    No sweat :-).<br>
    <br>
    <blockquote
      cite="mid:216A2ADF-9067-4E54-B3F0-A9810562B38C@refined-audiometrics.com"
      type="cite">
      <div class="">but don't the things you advocate require access to,
        or rewriting of, the JS Server side? Or are you performing this
        magic from the client side? That’s all I have access to in these
        foreign tools.</div>
      <br>
    </blockquote>
    <br>
    <br>
    Closures are basically what the RTOS (real-time operating systems)
    guys call "processes".<br>
    <br>
    The difference between an RTOS process and a closure is that a
    process *cannot* call it's peers directly, except by resorting to a
    "special API" called "IPC", handled by the RTOS scheduler.<br>
    <br>
    To duplicate the look-and-feel of processes, one must simply stop
    allowing oneself to "call" peer routines / closures.<br>
    <br>
    You have a single distinguished routine (called "the scheduler") and
    you "return" to it.  The scheduler maintains a queue of ready-to-run
    closures and calls them one at a time (in "random" order).<br>
    <br>
    You send "messages" to peer closures (think Actors, CSP, FBP).  The
    scheduler keeps a queue of pending messages (there are many
    optimizations possible), peels one message off of the queue and
    invokes a closure with that message.<br>
    <br>
    The closure deals with the message, may produce new messages, then
    returns to the scheduler.  And the cycle repeats.<br>
    <br>
    The closures have to promise to "return promptly" to the scheduler
    and to not leave any junk (persistent data) on the stack (i.e. use
    closed-over variables instead of auto variables).<br>
    <br>
    Does what / how I am saying this make sense?  I've been beating this
    horse for a long time and most people don't get it.  I would be glad
    to continue to answer questions.<br>
    <br>
    [Admittedly, I haven't done this on a js client, yet, but I see no
    road-blocks, my node.js code should port directly].<br>
    <br>
    pt<br>
    <br>
    I strongly recommend Rob Pike's talk "Concurrency is not Parallelism
    - It's Better" to understand why this is a good way to think.<br>
    <br>
    <br>
  </body>
</html>