> Adam Haberlach writes:
> > Typically (on a well-written OS, at least), the spawning of a thread
> > is much cheaper then the creation of a new process (via fork()).
>
> This would be well worth testing on some representative sample
> systems.
>
> Within the past year and a half at one of my gigs some coworkers did
> tests on various platforms (Irix, Solaris, a few variations of Linux
> and *BSDs) and concluded that in fact the threads implementations were
> often *slower* than using processes for moving and distributing the
> sorts of data that they were playing with.
>
> With copy-on-write and interprocess pipes that are roughly equivalent
> to memcpy() speeds it was determined for that application that the
> best way to split up tasks was fork()ing and dup().
This brings up a good point. Threads are mostly useful when you have
multiple processes that need to share lots of data, and the interprocess
overhead is excessive. Because we already have that shared memory area,
this benefit of threads doesn't buy us much. We sort of already have
done the _shared_ part, and the addition of sharing our data pages is
not much of a win.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026