Threads vs Processes

[Steve Holden]

Carl J. Van Arsdall wrote:
> Paul Rubin wrote:
> 
>>"Carl J. Van Arsdall" <cvanarsdall at mvista.com> writes:
>>  
>>
>>>Processes seem fairly expensive from my research so far.  Each fork
>>>copies the entire contents of memory into the new process.
>>>    
>>
>>No, you get two processes whose address spaces get the data.  It's
>>done with the virtual memory hardware.  The data isn't copied.  The
>>page tables of both processes are just set up to point to the same
>>physical pages.  Copying only happens if a process writes to one of
>>the pages.  The OS detects this using a hardware trap from the VM
>>system.
>>  
> 
> Ah, alright.  So if that's the case, why would you use python threads 
> versus spawning processes?  If they both point to the same address space 
> and python threads can't run concurrently due to the GIL what are they 
> good for?
> 

Well, of course they can interleave essentially independent 
computations, which is why threads (formerly "lightweight processes") 
were traditionally defined.

Further, some thread-safe extension (compiled) libraries will release 
the GIL during their work, allowing other threads to execute 
simultaneously - and even in parallel on multi-processor hardware.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden