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

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?

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.

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

If your up for some good thread theory reading check out:
 http://www.gnu.org/software/pth/pth-manual.html

jam

----- Original Message -----
From: "Jason R Thorpe" <thorpej@zembu.com>
To: "Daniel S. Riley" <dsr@mail.lns.cornell.edu>; "John A. Maier"
<johnam@kemper.org>
Cc: <netbsd-users@netbsd.org>
Sent: Tuesday, August 29, 2000 8:58 AM
Subject: Re: native pthread support in 1.5


>
> On Tue, Aug 29, 2000 at 08:50:50AM -0400, Daniel S. Riley wrote:
>
>  > I dunno...reasonably knowledgeable people say the Solaris 2-level
>  > scheduler implementation has some serious warts--in particular, no
>  > preemption at the user level, and the rather ugly workaround,
>  > thr_setconcurrency().  See, for example
>
> Well... we won't be using the Solaris thr_* API at all... but userlevel
> preemption is something we plan to have.  We're not going to use a
> "one kernel-scheduled thread per user-level thread" model (this is, BTW,
> what Linux uses, and each thread also has a *different* PID) -- it's
> well-understood that this model doesn't scale well.
>
> The NetBSD model is going to be more like newer (e.g. Solaris 8)
> implementations -- LWPs to provide the kernel with a scheduling
> handle for user threads that block in the kernel (eliminates the
> big mess of emulation blocking I/O with non-blocking I/O in userspace),
> and downcalls from the kernel to let the user-level scheduler know
> about important scheduling events.
>
> --
>         -- Jason R. Thorpe <thorpej@zembu.com>