thanks everybody for the info.
I will follow up the link on the usenix paper(s).
regards
-kamal

--- "Nathan J. Williams" <nathanw@wasabisystems.com>
wrote:
> Kamal Prasad <kamalpr@yahoo.com> writes:
> 
> > --- Bill Studenmund <wrstuden@netbsd.org> wrote:
> > > Kernel threads are available and used. User
> level
> > > threads have no kernel
> > > support; you have to use userland threading
> > > libraries.
> > > 
> > is there an architevctural reason why we cannot
> attach
> > userlevel threads to a kernel level thread (the
> way
> > its done in Solaris)?
> 
> The kernel threads Bill refers to are really
> process-level entities
> that simply spend their entire life in the kernel.
> Referring to them
> as "threads" is somewhat misleading; while the
> "kernel threads" share
> the kernel address space, they're scheduled in the
> traditional
> cooperative way. Our kernel is not a generally
> preemptable thread
> system.
> 
> It is possible to create multiple kernel-scheduled
> entities
> (processes, really), have them share an address
> space, and bind
> userlevel threads to them. We have the __clone()
> system call, adopted
> for Linux and principally implemented for Linux
> emulation, that does
> this.
> 
> On the branch I've been working on ("nathanw_sa"),
> there is an
> additional, somewhat Solaris-like LWP construct,
> which is the
> schedulable entity, and there can be multiple LWPs
> per process. It is
> possible, with that code, to bind user threads
> one-to-one with LWPs in
> a process.
> 
> The thread system I'm implementing on the branch
> does something
> more complicated, hopefully with some benefits to
> show for it; have a
> look at my Usenix paper on the subject at
> http://web.mit.edu/nathanw/www/usenix/.
> 
>         - Nathan


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com