Threads vs Processes

[bryanjugglercryptographer at yahoo.com]

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