I got started with programming back in the DOS days. One of my early projects involved overriding the keyboard interrupt service routine with my own. Now I'm trying out NodeJS to update myself, and I feel there is a similarity between the non-blocking design of NodeJS and my old experience with interrupt service routines (ISR). My guess is the similarity would be the keyboard ISR would wait for a key press input signal from the keyboard, while NodeJS waits for a web request. When the input arrives, both NodeJS and the ISR need to hurry to handle the request and say they're done in case a new input arrives. That is, there is a penalty for a CPU bound task slowing down the next web response or the next keyboard key input. Is this observation a reasonable understanding? I'm new to NodeJS so perhaps I'm missing an important difference or just incorrect in some fundamental way.
Node.js Interrupt Handlers – Implementing Interrupt Handlers in Node.js
ms-dosnode.js
Related Solutions
I think you are looking for the async module on npm.
Find it on github at https://github.com/caolan/async.
This module supports a lot of utilities for doing things asynchronously that are typically synchronous, like a linear search through an array.
More importantly for you, it allows for chaining asynchronous functions. It has 2 modes you can use: parallel or serial. In parallel mode, it runs the async functions in parallel (this is a lie as nothing in parallel in node.js, but it will simply context switch based on I/O calls as any async stuff works in node). In serial mode, it runs each function after the previous one finishes by chaining the callbacks together.
From the quick examples on their README:
async.parallel([
function(){ ... },
function(){ ... }
], callback);
async.series([
function(){ ... },
function(){ ... }
]);
So if I understand your question correctly, what you want to do is this:
async.series([
obj.setup.bind(obj),
obj.do_something.bind(obj),
obj.do_another_thing.bind(obj),
obj.end.bind(obj)
]);
This is how under the hood async will handle this and you could do it yourself if you don't want to use the module:
obj.setup(function () {
obj.do_something(function () {
obj.do_another_thing(function () {
obj.end();
});
});
});
As you can see, this gets messy as you add more and more functions to the chain. That is why the async.series call is more maintainable.
You also need to update your functions to use callbacks. No matter what tools or frameworks you use, if your async functions don't pass a callback, there is no way to know whey they finished and therefore no way to move to the next function in the chain.
Function changes:
var _ = {
"setup" : function(callback){
...
return this
},
"do_something" : function(callback){
o.async_method(callback)
return this
},
"do_another_thing" : function(callback){
o.async_method_thingy(callback)
return this
},
"end" : function(callback){
o.async_method_foo(callback)
return this
}
}
You'd be better off using that extra bandwidth to spoon feed the map to the users as they discover it.
As you've noticed, anything client side can be easily hacked. You might think of a fancy way to encrypt the data, but you'd still have to send the decrypt keys to the browser.
For that matter, you don't really know if you're talking to a browser at all - you're just sending data over a TCP port to a computer that kind of maybe sort of looks like it might be a common web browser.
Best Answer
Sort of.
Interrupt Service Routines are really just hardware hooks so that the keyboard or other hardware device can make a subroutine call to the operating system while maintaining a degree of isolation. There's a lot more to it, of course, and if the method appears to be asynchronous, it's only because operating systems back then were capable of rudimentary task switching, or maybe even cooperative multitasking.
Node.JS's mechanism of operation is a bit different. Node.JS has an event loop that receives requests, each of which it assigns to a new thread under the covers. An async handler is registered to receive the eventual result of the requests. Everything happens at a much higher level of abstraction.