From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 10:26:28 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 024F316A403; Mon, 30 Oct 2006 10:26:28 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85E8D43D5A; Mon, 30 Oct 2006 10:26:22 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9UAPtMu099205; Mon, 30 Oct 2006 02:25:55 -0800 (PST) Date: Mon, 30 Oct 2006 11:25:51 +0100 Message-ID: From: gnn@freebsd.org To: David Xu In-Reply-To: <200610301649.26429.davidxu@freebsd.org> References: <200610301649.26429.davidxu@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-threads@freebsd.org Subject: Re: libthr status X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 10:26:28 -0000 At Mon, 30 Oct 2006 16:49:26 +0800, David Xu wrote: > As some of you may know that I have been working on 1:1 threading > for years on FreeBSD. In the past years, I have polished it again and > again. > Thanks for posting this. > 1) The current status of libthr is that all features listed in > /usr/include/pthread.h and /usr/include/pthread_np.h are supported > by libthr except followings: > > 1.1) libthr does not support PROCESS scope, a threads created in > libthr is SYSTEM scope threads, a kernel thread within system > contention scope. The PROCESS scope is supported by libpthread using > userland scheduler. > > 1.2) libthr does not support PROCESS SHARED mutex and other pthread > synchronous objects. Study pthread_mutexattr_setpshared if you are > interested. libpthread does not support the feature too. But libthr > has better potential than libpthread to support it, since our kernel > umtx code support shared memory map, study kern_umtx.c if you are > interested. > > 1.3) libthr does not support some level of robust mutex which is > found in recent Linux kernel and glibc and Solaris, this is only > required if PROCESS SHARED mutex is supported. libpthread does not > support the feature too. This is not required by POSIX, but in some > commercial implementations. > > 1.4) pthread_getconcurrency and pthread_setconcurrency in libthr are > no-op, because it is 1:1 and does not have PROCESS scope thread. it > is supported by libpthread to tune number of UPCALL structures. > > 1.5) pthread_switch_add_np and pthread_switch_delete_np are no-op in > libthr, they are remanet of libc_r. > > 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? > 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? Thanks, George