[ On Thursday, January 10, 2002 at 23:51:44 (-0500), Marina Brown wrote: ]
> Subject: Re: Thread Performance in NetBSD
>
> It's odd how sometimes the more antiquated ways like forking work better.

No, I don't think it is odd at all.  ;-)

> I would MUCH rather use threads, but postgres seems like a better choice
> a lot of the time.

I'd much rather use multiple communicating processes.

Threads have their places, but those are usually within OS kernels and
maybe in a very tiny number of applications where multiple events need
to give the impression of proceeding smoothly and simultaneously (which
almost always means only in user interfaces and maybe some real-time
interfaces, though indeed a very few types of communications systems can
also benefit from multiple light-weight threads when shared memory and
system semaphores are too expensive to use).  I don't think a database
engine has to use threads, provided it's designed in such a way that it
doesn't suffer from the cost of the IPC mechanisms it uses.

Programming (correctly and safely) for threads is known to be very much
more difficult than just programming for simple unthreaded processes,
even when you need several or many of the latter an they must all
communicate and co-operate correctly and safely themselves.

There have been many debates about this in many circles (including in
formal academic publications), but I think the best demonstration is a
count of the number of experienced and capable kernel programmers who do
thread-based programming well vs.  the number of experienced and capable
applications programmers who barely know how to spell "thread".  :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>