I'll add to greelgorke answer that shared state between parallel workers is more and more considered an antipattern these days. Erlang uses messages passing, Go has channels (kinda like streams) and node has a several message based communication pattern (streams, WebWorker API, dnode, etc.). Node.js doesn't force you to use these patterns, but it certainly promotes them.
On Monday, 18 February 2013 10:07:18 UTC+1, greelgorke wrote: > > threads-a-gogo for small but cpu-heavy tasks. > child_process.fork for permanently running worker-like services (or use > tools like mongroup) > cluster for horizontal scaling on a single machine to use all CPU-cores > > Node is designed mainly for I/O intensive Use Cases, in fact it was born > out of the idea to build up a web server, which can handle many concurrent > connections and can scale horizontal w/o pain. easy integration of > websockets support is on top of it. this is it, what node is for. > > as much as i like the idea to do almost all in node, i admit, there are > tasks, that are not good to solve in node. They are rare, but they are > there. And node have no thready for a reason: the complexity. classic > threads are able to share state. this is the root of evil in multithreading > :) other solutions on thread basis are better i.E. erlang has threads with > message passing only, other platforms uses other technics for thread > communication. > > Node provides no multithreading to the developer, but it uses threads > under the hood, so it is still efficient, at least as efficient as your > longest computation. > > "true parallelism" !== threading. threads is one possible solution to > implement parallel tasks. Node provides you with child_process and cluster > to process-based solutions, web-services are another one, that distribute > your app over network. and you have the ability to pass the task to > completely other platform/tool/app if it suites it. a simple example here > is to provide image scaling in your node app via passing the scaling work > itself to imagemagick, which is a better tool for this kind of tasks. > > before i start to use threads in node i'd first look if i can delegate the > task to some other tool or service. node is good at communication and > streaming, and as such it also good as a dispatcher or commander in a > cluster of services. > > Am Montag, 18. Februar 2013 01:15:48 UTC+1 schrieb RF: >> >> Hi, >> >> I'm CS student who is new to Node, and I have two questions: >> >> 1. Is there currently an existing mechanism (e.g. module, core >> functionality) that allows Node applications to spawn multiple threads >> (to >> take advantage of multiple cores for true parallelism) ? >> 2. If not, would this be a desirable feature? >> >> My understanding is that Node applications use a single thread to handle >> everything by queuing events on an event loop to be processed sequentially. >> I also understand that this is the core feature that allows Node to grant >> efficiency gains for specific types of applications, and is the (main?) >> source of Node's popularity. >> >> Given this fact then (and assuming that it's correct), it would seem >> counter-intuitive to enable multi-threaded functionality in Node when there >> are other languages/frameworks available potentially more suited to >> multi-threaded behavior. >> However, an example use case that I'm thinking of is a situation whereby >> an existing Node application needs to be adapted or extended with some >> functionality that would benefit from true parallelism. >> So, maybe 3 or 4 threads could be created that would handle 3 or 4 tasks >> more efficiently than Node's existing sequential behavior, while still >> taking advantage of Node's established execution model in other areas of >> the application. >> >> I was thinking along the lines of creating a Node module that exposes an >> interface for creating threads and supplying them with the necessary >> function (and also some mechanisms for dealing with shared data concurrency >> and consensus issues). >> I have searched unsuccessfully through available resources in an attempt >> to answer the above questions, so I'm hoping that someone can help me out. >> >> Regards, >> -Rob >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
