Ben Tilly wrote: >>As for dealing with something "computationally slow," I assume POE and >>other similar event loop implementations support a mechanism for >>yielding to the event loop. > > Yes. But now you have the problem that when you use cooperative > multi-tasking, you can only take advantage of one CPU. And multiple > CPUs is a direction that computers are heading.
Good point. I was arguing from a devil's advocate perspective above. Unlike Uri, I'm happy to leave behind my experiences with event loops and cooperative multi-tasking, and prefer a threading model, even if current implementations in Perl aren't so efficient. > In fact, given the fact that OS designers have noticed > that communication between threads is faster if all threads are on one > CPU, multiple processes potentially scale a lot better on one machine > than multiple threads. (And multiple processes let you split things > across a server farm for real scalability.) That's an implementation detail that is likely to change over time. As virtualization tools become more sophisticated, the distinction between threads and processes will probably become less significant. (For example, the virtualization manager might notice that two threads in a process have no shared memory, so it send one of them off to another CPU.) The larger point your making, which I agree with, is that if you've taken the time to split up an application into separate processes or even threads, you've given the OS what it needs to be able to optimize the multi-tasking. In contrast, an event loop can't be unraveled by the OS. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: https://www.linkedin.com/e/fps/3452158/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
