Date: Mon, 30 Oct 2006 21:50:05 +0800 From: David Xu <davidxu@freebsd.org> To: freebsd-threads@freebsd.org Cc: gnn@freebsd.org Subject: Re: libthr status Message-ID: <200610302150.05499.davidxu@freebsd.org> In-Reply-To: <m2lkmyksls.wl%gnn@neville-neil.com> References: <200610301649.26429.davidxu@freebsd.org> <m2lkmyksls.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 30 October 2006 18:25, gnn@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. > > 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. > Thanks, > George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610302150.05499.davidxu>