> Multi-process + IPC is sooo 70's. well i speak about processes distributed over a network and today we call that webservices, but it still the same idea, application which holds it's parts in different processes doing IPC. a REST request is IPC over HTTP :)
again, threads are ok for a single application, and as long you do not share in-memory-state for communication, thats cool. TAGG utilizes events so its cool too. but if you have to distribute your applications modules over a network, you have to design it different. Just to say something is so 70s is a way to be blind ;) Am Freitag, 15. Februar 2013 17:18:36 UTC+1 schrieb Jorge: > > On 15/02/2013, at 13:14, greelgorke wrote: > > > all 3 solutions have their caveats. > > > > of course you can get a node_cluster to block, no, prob. > > > > the service process is a different kind. it's master-worker system where > master just recieves messages and queues them up and respondes to clients, > and workers are fetching job requests from master, calculate and notify > when done. the master is still responsive, because it just handles IPC I/O > and manges the queue-based dispatching. the works block their own > eventloop, but it's ok because they are detached from the rest of the app. > it's similar idea like threads, but better to distribute over physical > machines and the creation cost is paid on startup once. in fact you can use > threads to implement the worker, but as fully detached process you can > distribute even the worker. > > > > to be honest, IF i have an app with high traffic, then i don't want the > whole machine doing anything else but to handle this traffic, that's the > case where threaded solution may reach it's limits. of course you can scale > the whole thing horizontally. it's a decision to make depending on the > requirements. > > > > PS: i didn't say threads are bad, or threads-a-gogo. i just say there > are cases, and they aren't rare, where threads are not good (enough). thats > all. > > Multi-process + IPC is sooo 70's. One should only have to suffer it to > scale across machines, but, within the boundaries of a single machine, just > to exploit multi-cores? No way. > > Take a look at your computer's activity monitor: several hundreds of > threads but just tens of processes... how can it be? How so if the way to > go multi-core were multi-process, there are hundreds of threads? > > On mine right now: 54 processes, 293 threads. Mail:13 threads, Safari:15 > threads, pid 0: 64 threads... Why not 15 Mail processes? Because it would > be silly. > > Also, when you have a single instance of your app programming becomes > easier, because you don't have to go re-creating the app's context, nor > cloning it, nor keeping it synchronized across a bunch of separate > processes. > > To keep node ticking, you just need an API to move blocking code out of > its main/event loop thread, to a worker thread if you like to call it so, > yes, and that's what TAGG lets you do, within a single process, without the > hassles of multiple processes + IPC + lost app's contexts to re-create. > -- > Jorge. -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
