Andrew Doran <ad@netbsd.org> writes:

> It's not difficult to construct artifical benchmarks to show for
> instance, pthread_cond_wait() is now slower or that thread creation
> is now slower. Ok, but we will be tuning the new system as time goes
> on, and, for most real world applications 1:1 is only going to bring
> benefits in the long run.

Actually, it has been my experience that for most real world
applications that have significant numbers of threads, even on large
scale SMPs, m:n is more efficient.

There's almost no workload for which it is less so.

> I think it's important to note that with the release of NetBSD 5.0
> we will be able to provide working pthreads on _all_ platforms, a
> threading implementation that works on MP systems, and importantly a
> threading implementation that is robust.

As I understand it, until very recently, you were planning on
preserving m:n threads for the uniprocessor case. We're not asking
that you solve the general SA debugging problem. We're simply asking
that you leave the m:n threads for the uniproccesor case as a compile
time kernel option. We've fixed them to our satisfaction and will fix
them further if we find them broken.

What we want is something that was a goal of yours until recently and
that's technically just not that hard to do.