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
}
}
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.
Best Answer
Comparing Node.js to Java is somewhat like comparing apples to oranges and more like comparing a dictionary to a grammar textbook (thanks scriptin).
Node.js is a quasi-framework written in JavaScript using Google's V8 JavaScript engine to build the JavaScript code into native machine code that can be used server-side (instead of interpreting the JS code in real-time).
Java is a language (not a framework) to which an implementation of the JDK (i.e. Oracle JDK vs. OpenJDK) can see fit how to implement the underlying language constructs (threads, I/O, etc.).
Node.js does not have a threading model, that is, you cannot spawn a thread directly through any API Node.js has. This is because it utilizes JavaScript (i.e. ECMAScript) which does not support multi-threading (since JavaScript was not originally meant for server side development). This does not mean that it is not multi-threaded. On the contrary, Node.js uses a thread pool to manage a lot of the async-I/O and event system that you (the user of Node.js) can hook into (just like JavaScript on the client). So as you stated:
Yes.
In a Java environment, you can spawn threads in user code, but it should be noted that the underlying mechanisms that spawn the threads (i.e. the JVM C code) are the same system API's called to create and manage the threads in Node.js. In other words, both will call
pthread_createfor POSIX platforms orCreateThreadfor Windows. In this way, the resources used are the same on that front.Where this thread model and resource usage differs is when a user wants to create more than 1 thread; multiple threads might mean context switches which can incur additional resources. This is true of any language though, since threading is an OS level concept and not something a language need support, so if you (as the developer) are building a multi-threaded application, you would (should) be aware of these caveats and build your code accordingly (i.e. handle the resources/threads such that the application has as little context switching as feasible).
Continuing from that, you state
This question cannot be directly (read, easily) answered since a simple Node.js app that were ported to Java (or vice versa) could result in varying resource usage based on a slew of different factors and ultimately you would have to do the testing yourself to see which would be better for that scenario.
To this though, the "less consuming" quote is probably referring more to the fact that running a Java based applet would require the Java Virtual Machine and the Java environment, which do consume substantial amounts of resources (for different reasons) compared to Node.js (which runs as a "native" app), but just because something consumes more resources does not mean it's "worse". And this is why additional testing would need be done to confirm.
I hope that can help add clarity.