"the problem with threads"

[Paul Vixie]

> Well I don't think that threads are necessarily bad. Just like any other
> tool, it's appropriate in some places and not in others.

they are bad for what they were originally designed to do.  they're quite
good at what they actually do.  it's a pity that what they actually do is
not very often useful.

> > i do not myself know what else we should do, unless it's the apache fork()
> > model.
> 
> And how would that help?

zero coordination between processors for most operations, with a few pipes
for control information, would let all N processors convoy in select() or
read() or whatever.  if the kernel is well prepared for this (most are not)
then the only locking that'll happen is in selwakeup() or the local kernel
equivilent.  it would mean killing and restarting a bunch of worker processes
every time zone maintainance concluded, and it would not help with recursion
where every transaction can potentially modify a cache which ought to be
shared.  but it would be faster than any thread-based approach i have seen,
during the longish intervals where no zonemaint occurs.