btw. we're off topic :D Am Freitag, 15. Februar 2013 20:22:10 UTC+1 schrieb greelgorke: > > > 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.
