> So an app written with threading will show up as one process?

Yes.

> If I am understanding you correctly, The NetBSD implementation will be a LWP
> with kernel tie ins to keep calls that block [i.e. connect(), read()] from
> hanging the other threads?

Yes.

> If this is true, then how might this be moved to a multiprocessor
> architecture model?  I realize that LWP threading has typically superior
> performance to HWP, where number crunching is *not* involved, but it won't
> take advantage of a multiprocessor system.

there's a terminology mismatch going on here.  

LWP is sometimes used to refer to userland-only threading.  this is
not what netbsd is doing.  We're using the solaris-like terminology
here; a process has multiple kernel-visible lwp's within it.

The userland scheduler will be responsible for assigning user-level
pthreads to the kernel lwp's.

Preempted user-level threads, as well as threads which are waiting for
user-level events (blocked waiting for a pthread_mutex_lock or
pthread_cond_wait) will not tie up a kernel lwp.

> I assume that floating point will be an in kernel solution to maintain
> performance where number crunching is required.

huh?  floating point will run on the native FP hardware unless
emulation is needed.

					- Bill