libkse -> libpthread

[Igor Sysoev]

On Mon, 21 Apr 2003, Daniel Eischen wrote:

> On Mon, 21 Apr 2003, Terry Lambert wrote:
> 
> > Jeff Roberson wrote:
> > > On Mon, 21 Apr 2003, Daniel Eischen wrote:
> > > > Since libkse seems to be generally useful, anyone mind if I
> > > > go back to installing it as libpthread?
> > > 
> > > There is some question over whether kse or thr will be the default
> > > threading implementation for 5.1.  I think this should be discussed before
> > > we decide on what lib uses libpthread.
> > 
> > Isn't libthr really just libkse with N = M?
> 
> Yes, I wasn't going to bring that up, though.
> 
> > These should behave exactly the same, right?  It should even be
> > possible to drop the UTS out of the picture for everything but
> > signal handling, I think (i.e. it would never get upcalled) in
> > the 1:1 case, if this were done?
> 
> Libpthread can be made to behave the same as libthr just
> by forcing every thread to be scope system.  Currently,
> the implementation for scope system threads does have
> a small amount of overhead in that they still get upcalls
> after the thread blocks in the kernel (in this case
> the KSE just reenters the kernel with kse_release()
> and waits for the thread to become unblocked).  These
> KSEs also require a small stack separate from the
> thread's stack.  The code is in place (in the UTS) to
> not require a separate stack and not get any upcalls
> for these threads, but we just need a bit more
> kernel work to optimize this overhead away.

But why is not it implemented via setting kse_mailbox.km_curthread to NULL ?
As I understand it's way to disable upcalls when UTS is preempted
by the kernel (the time slice ended, the page in operation, etc.)
i.e. UTS should always run as 1:1 thread.
Had it been changed ?  How is UTS protected now ?


Igor Sysoev
http://sysoev.ru/en/