On 16-07-05 01:31 PM, David McClain wrote:
Hi Paul,
Please forgive my ignorance,
No sweat :-).
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.