libthr status

[gnn at freebsd.org]

At Mon, 30 Oct 2006 21:50:05 +0800,
David Xu wrote:
> 
> [1  <text/plain; iso-8859-1 (7bit)>]
> On Monday 30 October 2006 18:25, gnn at freebsd.org wrote:
> 
> > > 1.6) setrlimit for number of kenrel threads, it is not done, one-day
> > > work.
> >
> > Cool that it's only a day.  Is this something you're hacking on now?
> >
> 
> I will hack at kernel side, but who will hack userland utilities ?
> e.g the /usr/bin/limits program.
> 

How hard is that to do?  If it's "easy" then I can sign up to do that.

> > > 1.7 CPU binding API, not done in libthr, found in other OSes.  libpthread
> > > does not support it either.
> > >
> > > 1.8 C++ object unwinding when pthread_exit is called(), I found it
> > > is support by debian Linux and Solaris, I have sample implementation
> > > for libthr.
> >
> > Cool as well, though not as big a deal as setrlimit.
> >
> > > 1.9) I forgot something.
> > >
> > > 2) Things can only be used by root:
> > >
> > > 2.1) the real-time scheduling options can only be used by root, e.g,
> > > if you call pthread_attr_setschedpolicy() with parameter SCHED_FIFO
> > > or SCHED_RR, the thread can only be created by root, normal user
> > > will get EPERM errno. you can use it in libpthread, but it is not
> > > real-time, it is a static priority scheduling in userland scheduler,
> > > if you want to preemptable other threads or processes in the system
> > > when playing real-time multimedia or military program, no way!
> > >
> > > 2.2) the real-time scheduling is not safe, it can deadlock itself and
> > > the whole system if program behavors incorrectly, it should only be
> > > used by trusted programs.
> >
> > Are these (can these be) documented in the man pages?
> >
> No, they are not documented.
> 
If these limitations will be there for a while can you update the man
page?  If you like I can review that change for correctness.

Best,
George