Carl J. Van Arsdall wrote: > Alright, based a on discussion on this mailing list, I've started to > wonder, why use threads vs processes.
In many cases, you don't have a choice. If your Python program is to run other programs, the others get their own processes. There's no threads option on that. If multiple lines of execution need to share Python objects, then the standard Python distribution supports threads, while processes would require some heroic extension. Don't confuse sharing memory, which is now easy, with sharing Python objects, which is hard. > So, If I have a system that has a > large area of shared memory, which would be better? I've been leaning > towards threads, I'm going to say why. > > Processes seem fairly expensive from my research so far. Each fork > copies the entire contents of memory into the new process. As others have pointed out, not usually true with modern OS's. > There's also > a more expensive context switch between processes. So if I have a > system that would fork 50+ child processes my memory usage would be huge > and I burn more cycles that I don't have to. Again, not usually true. Modern OS's share code across processes. There's no way to tell the size of 100 unspecified processes, but the number is nothing special. > So threads seems faster and more efficient for this scenario. That > alone makes me want to stay with threads, but I get the feeling from > people on this list that processes are better and that threads are over > used. I don't understand why, so can anyone shed any light on this? Yes, someone can, and that someone might as well be you. How long does it take to create and clean up 100 trivial processes on your system? How about 100 threads? What portion of your user waiting time is that? -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list