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.
Closures are basically what the RTOS (real-time operating systems)
guys call "processes".
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.
To duplicate the look-and-feel of processes, one must simply stop
allowing oneself to "call" peer routines / closures.
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).
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.
The closure deals with the message, may produce new messages, then
returns to the scheduler. And the cycle repeats.
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).
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.
[Admittedly, I haven't done this on a js client, yet, but I see no
road-blocks, my node.js code should port directly].
pt
I strongly recommend Rob Pike's talk "Concurrency is not Parallelism
- It's Better" to understand why this is a good way to think.