Re: Processes vs Threads

In article <3984pm$1es_at_mail.fwi.uva.nl>

           casper_at_fwi.uva.nl "Casper H.S. Dik" writes:

> psb_at_sambusys.demon.co.uk (Paul Beardsell) writes:
>
> >Once upon a time a Unix fork() was expensive. And lite processes
> >seemed a good idea. But not anymore. fork() takes no longer than
> >pThreadCreate() (or whatever it is called - I can no longer remember.)
>
> Fork() is still very expensive. More expensive than creating threads.
> Even the copy-on-write implementations are expensive (in the order
> of the size of the process forking plus a constant). You need to
> mark all read-write pages as copy-on-write. Stuff like share groups
> and rfork() are better in this respect and those can do anything
> you can do with threads.

What about the overhead of running the thread scheduler? Of course I refer to the copy-on-write implementations. pThreads by default do a 32K malloc upon thread creation. fork() doesn't do so. Tell me what pThreadCreate() doesn't do that fork() does do? The man pages for lite versions of fork() [I suppose rfork() is one of those] now advise you to use ordinary fork() because they are the same.

> Some things are threaded more easily than fork()ed (in the traditional
> way). Traditional fork()/mmap() also doesn't come with the locking
> necessary or with hideously expensive locking (the shm* case).

What locking can threads do than is cheaper than semaphores used by co-operating Unix processes?

> Casper
>
 

-- 
Paul Beardsell                          SAM Business Systems Ltd
~~~~~~~~~~~~~~                          21 Finn House, Bevenden St,
pbeardsell_at_cix.compulink.co.uk          London, N1-6BN, UK.
psb_at_sambusys.demon.co.uk                (+44 or 0)71 608-2391