On Fri, Jun 20, 2003 at 04:23:12PM +1000, Charlie Allom wrote:
> On Fri, Jun 20, 2003 at 06:08:59AM +0000, Sean Davis wrote:
> > current state of affairs (especially on SMP machines, from what I read on
> > the lists) counts as stable by any definition of the word.
> > 
> 
> This is the same argument as the UFS2 checkin.

No, it isn't.  The problems caused by the UFS2 checkin were quickly
fixed, essentially as soon as they were reported in any useful way.

The problems caused for users with multiprocessor systems by the
pthread checkin have been well-understood since some time before
the code was committed.  No progress has been made, and as far as
I know, no work is being done.  Now, it's all well and good to say
"well, it's a volunteer project" but generally that's not the way
we do things (leaving things broken for months on end by new code), 
and given the "benefit" of hindsight, I have to guess that "must not 
break multiprocessors" would have been a good addition to the criteria 
for the merge of the pthread code onto the trunk in the first place;
because very atypically for NetBSD, what actually happened was a major 
regression in system functionality that has lasted for a long time and 
doesn't show any sign of letting up soon.

This is busted enough -- and has been busted enough for long enough --
that it's causing major sites to seriously reconsider using NetBSD.
That's not a good thing, and hopefully it will change soon.

Thor