> Forking is a poor man multithreading. It was developed when in-process
> light threads was rare in full fledge operating systems (as opposed to
> real-time kernels). Forking has higher overhead because of the
> replication of the entire data space of the project and requires more
> complex synchronization between the threads because of the address space
> separation.

I understand what you say but imho forking is a *rich* man's
multithreading. Because when you fork you really want to. With light
threads the thread-starting application cannot exit and leave the thread
running usually. You usually fork to start a server in the background, or
some other heavy item that needs to run by itself.  Nowadays a fork
implies copying less since code is shared by concurrently running copies
and the data area is usually small at the time of the fork. And
lightweight threads are also available if you want them.

0.02 bits,

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body