It's sort of glossed over, but the async APIs that Node.js relies on to interact with i/o resources such as web service calls, database access, memcached access are going to execute on some thread context other than the Node.js thread in order to behave asynchronously.
So it's a wee bit of a misnomer in a way to say that Node.js is "single-threaded". Perhaps a bit better way to put it is that it's a: single-threaded, event-driven HTTP processing framework programmed with JavaScript. So, yeah, the guy that gets to code the app in JavaScript gets to enjoy a single-threaded programming model. Yet somebody has to do the drudge work of dropping down to code in C or C++ in order to implement those async APIs. That code will have to deal explicitly with threading or underlying operating system i/o calls that are themselves asynchronous - and it will have to deal with thread synchronization for when data needs to be marshaled from and to the Node.js event thread. All very much the same kind of issues as a multi-threaded Java Swing application, which, of course, has a main thead that always executes the GUI code of Swing. That main GUI thread can interact with other threads to do things asynchronously, but there has to be care in using safe techniques of marshaling data between thread context. Some other worker thread just can't go and start directly mutating the state of Swing GUI objects. So these Node.js plugin authors still have all the same old multi- threading muck to contend with. The idea, am sure, is to build up a library of plugins that satisfy most kinds of popular i/o resources. Yet those have to be maintained across platforms. Currently Node.js is centric to just POSIX style platforms. Windows has to suck it up (maybe MingW would be helpful here - I've had success in working with zeromq by building it with MingW, and there's now MingW64). If your project needs to do async interaction with some resource that no one has written a Node.js adapter for yet, then your project is going to need greater than just JavaScript only skills. Certainly a lot of typical web sites could be built by following a well traveled path to where everything needed is already there. Yet if one wanted to start trying to use Node.js pervasively in enterprise computing scenarios, then there will be other kinds of input that need to be processed than just HTTP. Most enterprise distributed systems have a wide mixture of messaging (JMS and various other proprietary systems, e.g. Tibco, et al), raw socket communications (e.g., OASYS), or you might be orchestrating a building full of automation devices where you're using a proprietary real-time network layer, such as with Beckhoff controllers. I've enjoyed using Java app servers (and C# .NET) for enterprise distributed computing because I can build any manner of bean to handle the various flavors of i/o - and create nice abstractions such as a message bus with adapters. HTTP servlet are a very minor affair in such systems - usually relegated to just providing web console UIs. Is why I've referred to Node.js as a "web RAD" solution. Not seeing it as a general basis for enterprise distributed architecture. Of course it is web programming that everyone is always constantly fixated on in the public Internet forums. If you came from Mars and started ease- dropping, you'd pretty well think that programming solutions that appear in a web browser is the only kind of software that exist. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
