From owner-freebsd-threads@FreeBSD.ORG Sun Oct 29 03:56:13 2006 Return-Path: X-Original-To: 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 CE9DE16A415; Sun, 29 Oct 2006 03:56:13 +0000 (UTC) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE0743D6D; Sun, 29 Oct 2006 03:56:08 +0000 (GMT) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.35]) by a50.ironport.com with ESMTP; 28 Oct 2006 20:55:59 -0700 Message-ID: <4544264F.5050703@elischer.org> Date: Sat, 28 Oct 2006 20:55:59 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Xu References: <200610290815.25252.davidxu@freebsd.org> In-Reply-To: <200610290815.25252.davidxu@freebsd.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: peter@freebsd.org, Daniel Eischen , gnn@freebsd.org, Kip Macy , threads@freebsd.org Subject: My suggested path for threading. 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: Sun, 29 Oct 2006 03:56:14 -0000 I suggest that we remove the fairness code. that will remove a lot of the complexity. then both libraries will be more independent of each other and the scheduler. libpthread will have system and process scope threads. libthr will have only system scope threads but will probably be the more efficient library for the larger set of processes, while libpthread will be more efficient for a smaller set. Given this, I suggest the following path: 1/ remove the fairness code.. I can do this in the 2nd part of next week. I will be on vacation then. 2/ When it is up to it, make libthr the default threading library. I say this because MOST threading applications are very simplistic in their use of threading and the simpler threading infrastructure for 1:1 threading allows for easier optimisation. They usually use threading for IO parallelization and in this case, 1:1 and M:N devolve to effectively the same thing except that M:N has more overhead. 1:1 is more efficient in this case. 3/ Keep libpthread around. I believe strongly that there is a class of threaded app where M:N (after optimization) can leave 1:1 in the dust. This class of program instantiates many objects, each of which has a backing thread to implement some form of active behaviour. These threads usually never go to the kernel and typically come to life from a mutex or condition variable and then go to sleep again waiting on same. I have seen a test example of this class where M:N gave an order of magnitude speed up. 4/ continue to adhere VERY STRONGLY to our current practice of making the libraries RUN_TIME COMPATIBLE. (i.e. libmap can switch between them) I strongly believe that the problems people have reported with "KSE" are not problems with M:N threading as they are not using M:N threading but problems with the complexity added to the scheduler by the fairness attempt. I believe removing this will almost certainly fix those problems and if it doesn't it will narrow the search significantly. From owner-freebsd-threads@FreeBSD.ORG Sun Oct 29 04:14:35 2006 Return-Path: X-Original-To: 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 E703216A415; Sun, 29 Oct 2006 04:14:34 +0000 (UTC) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B4F43D5F; Sun, 29 Oct 2006 04:14:34 +0000 (GMT) (envelope-from prvs=julian=4503dd1c6@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.35]) by a50.ironport.com with ESMTP; 28 Oct 2006 21:14:33 -0700 Message-ID: <45442AA9.4040306@elischer.org> Date: Sat, 28 Oct 2006 21:14:33 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Julian Elischer References: <200610290815.25252.davidxu@freebsd.org> <4544264F.5050703@elischer.org> In-Reply-To: <4544264F.5050703@elischer.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: peter@freebsd.org, Daniel Eischen , gnn@freebsd.org, Kip Macy , David Xu , threads@freebsd.org Subject: Re: My suggested path for threading. 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: Sun, 29 Oct 2006 04:14:35 -0000 Julian Elischer wrote: > > I suggest that we remove the fairness code. > that will remove a lot of the complexity. > then both libraries will be more independent of each other > and the scheduler. (libthr already doesn't use it, and libpthread doesn't need it.. so it just adds complexity) > > libpthread will have system and process scope threads. libthr > will have only system scope threads but will probably be the more > efficient library for the larger set of processes, while libpthread > will be more efficient for a smaller set. > > Given this, I suggest the following path: > > 1/ remove the fairness code.. > I can do this in the 2nd part of next week. I will be on vacation then. > > > 2/ When it is up to it, make libthr the default threading library. > I say this because MOST threading applications are very simplistic in their > use of threading and the simpler threading infrastructure for 1:1 threading > allows for easier optimisation. They usually use threading for IO > parallelization and in this case, 1:1 and M:N devolve to effectively > the same thing except that M:N has more overhead. 1:1 is more efficient > in this case. > > 3/ Keep libpthread around. I believe strongly that there is a class of > threaded app where M:N (after optimization) can leave 1:1 in the dust. > This class of program instantiates many objects, each of which has a backing > thread to implement some form of active behaviour. These threads usually > never go to the kernel and typically come to life from a mutex or > condition variable and then go to sleep again waiting on same. I have > seen a test example of this class where M:N gave an order of magnitude > speed up. > > 4/ continue to adhere VERY STRONGLY to our current practice of making > the libraries RUN_TIME COMPATIBLE. (i.e. libmap can switch between them) > > > I strongly believe that the problems people have reported with "KSE" are > not problems with M:N threading as they are not using M:N threading but > problems with the complexity added to the scheduler by the fairness > attempt. I believe removing this will almost certainly fix those problems > and if it doesn't it will narrow the search significantly. > > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 08:49:34 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9721B16A415 for ; Mon, 30 Oct 2006 08:49:33 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-threads@freebsd.org Date: Mon, 30 Oct 2006 16:49:26 +0800 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610301649.26429.davidxu@freebsd.org> Subject: 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 08:49:35 -0000 Hi, 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. 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. 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. 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. David Xu 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 From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 11:08:44 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 6586916A719 for ; Mon, 30 Oct 2006 11:08:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0550843D77 for ; Mon, 30 Oct 2006 11:08:42 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k9UB8fBL086044 for ; Mon, 30 Oct 2006 11:08:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k9UB8ejw086040 for freebsd-threads@FreeBSD.org; Mon, 30 Oct 2006 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Oct 2006 11:08:40 GMT Message-Id: <200610301108.k9UB8ejw086040@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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 11:08:44 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72353 threads Assertion fails in /usr/src/lib/libpthread/sys/lock.c, o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash 29 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/74180 threads KSE problem. Applications those riched maximum possibl o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 10 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 13:50:15 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3B45316A403; Mon, 30 Oct 2006 13:50:14 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-threads@freebsd.org Date: Mon, 30 Oct 2006 21:50:05 +0800 User-Agent: KMail/1.8.2 References: <200610301649.26429.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610302150.05499.davidxu@freebsd.org> Cc: gnn@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 13:50:15 -0000 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 From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 18:23:22 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 8FE3F16A569; Mon, 30 Oct 2006 18:23:22 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 132E643DDD; Mon, 30 Oct 2006 18:23:17 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9UIN5Or006637; Mon, 30 Oct 2006 10:23:06 -0800 (PST) Date: Mon, 30 Oct 2006 19:23:02 +0100 Message-ID: From: gnn@freebsd.org To: David Xu In-Reply-To: <200610302150.05499.davidxu@freebsd.org> References: <200610301649.26429.davidxu@freebsd.org> <200610302150.05499.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 18:23:22 -0000 At Mon, 30 Oct 2006 21:50:05 +0800, David Xu wrote: > > [1 ] > 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. > 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 From owner-freebsd-threads@FreeBSD.ORG Mon Oct 30 23:18:23 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 36D6316A412; Mon, 30 Oct 2006 23:18:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: gnn@freebsd.org Date: Tue, 31 Oct 2006 07:18:15 +0800 User-Agent: KMail/1.8.2 References: <200610301649.26429.davidxu@freebsd.org> <200610302150.05499.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610310718.15763.davidxu@freebsd.org> 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 23:18:23 -0000 On Tuesday 31 October 2006 02:23, gnn@freebsd.org wrote: > > 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. > I think it is not hard, but I think one at least has to hack /usr/bin/limits, sh and csh which are in our base system. > > > > 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 I will update them and make them reviewed. Thanks, David Xu From owner-freebsd-threads@FreeBSD.ORG Wed Nov 1 15:26:34 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 DE21A16A47E; Wed, 1 Nov 2006 15:26:34 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F5A843D80; Wed, 1 Nov 2006 15:25:57 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kA1FP8Dd060784; Wed, 1 Nov 2006 07:25:08 -0800 (PST) Date: Tue, 31 Oct 2006 19:30:09 +0100 Message-ID: From: gnn@freebsd.org To: David Xu In-Reply-To: <200610310718.15763.davidxu@freebsd.org> References: <200610301649.26429.davidxu@freebsd.org> <200610302150.05499.davidxu@freebsd.org> <200610310718.15763.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: Wed, 01 Nov 2006 15:26:35 -0000 At Tue, 31 Oct 2006 07:18:15 +0800, David Xu wrote: > > [1 ] > On Tuesday 31 October 2006 02:23, gnn@freebsd.org wrote: > > > 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. > > > > I think it is not hard, but I think one at least has to hack > /usr/bin/limits, sh and csh which are in our base system. I will take on the task when you have the kernel side in place. > I will update them and make them reviewed. > Great! Thanks, George From owner-freebsd-threads@FreeBSD.ORG Wed Nov 1 18:07:43 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 10C3816A4D0; Wed, 1 Nov 2006 18:07:43 +0000 (UTC) (envelope-from prvs=julian=453a8fdc9@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5267A43D70; Wed, 1 Nov 2006 18:07:40 +0000 (GMT) (envelope-from prvs=julian=453a8fdc9@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.34]) by a50.ironport.com with ESMTP; 01 Nov 2006 10:07:39 -0800 Message-ID: <4548E263.80104@elischer.org> Date: Wed, 01 Nov 2006 10:07:31 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: gnn@freebsd.org References: <200610301649.26429.davidxu@freebsd.org> <200610302150.05499.davidxu@freebsd.org> <200610310718.15763.davidxu@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , 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: Wed, 01 Nov 2006 18:07:43 -0000 gnn@freebsd.org wrote: > At Tue, 31 Oct 2006 07:18:15 +0800, > David Xu wrote: >> [1 ] >> On Tuesday 31 October 2006 02:23, gnn@freebsd.org wrote: >>>> 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. >>> >> I think it is not hard, but I think one at least has to hack >> /usr/bin/limits, sh and csh which are in our base system. > > I will take on the task when you have the kernel side in place. > >> I will update them and make them reviewed. >> > > Great! > > Thanks, > George > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" in a manner of speaking, I wonder if that the thread limit should be just related to the process limit.. i.e. N threads count to be 1 process.. if you use linuxthreads of rfork() then you are limited to the process limit.. why should the other threads be different? just a thought.