From owner-freebsd-threads@FreeBSD.ORG Wed Nov 19 07:33:47 2003 Return-Path: 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 7AC3916A4D1; Wed, 19 Nov 2003 07:33:47 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id A89A343FBD; Wed, 19 Nov 2003 07:33:45 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id hAJFXigr042041; Wed, 19 Nov 2003 17:33:44 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3FBB8D3B.10009@he.iki.fi> From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: "Jacques A. Vidrine" cc: freebsd-threads@FreeBSD.org Subject: Re: threads and openssl X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 19 Nov 2003 15:33:47 -0000 X-Original-Date: Wed, 19 Nov 2003 17:33:15 +0200 X-List-Received-Date: Wed, 19 Nov 2003 15:33:47 -0000 Daniel Eischen wrote: >Can you guys try building with debugging enabled and get some >more info (with libkse)? I'd like to see if it's openssl or >the application, or our thread library. > > > Me? Everything works for me after doing the change described. If you donīt compile openssl thread-safe is crashing too violent option or is there some other concern? Pete From owner-freebsd-threads@FreeBSD.ORG Sat Dec 6 22:34:34 2003 Return-Path: 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 4159616A4CE for ; Sat, 6 Dec 2003 22:34:34 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 231CF43F75 for ; Sat, 6 Dec 2003 22:34:33 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hB76YVml028230; Sun, 7 Dec 2003 01:34:32 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Kostouros In-Reply-To: <3FD245FF.3040003@melbpc.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 07 Dec 2003 06:34:34 -0000 X-Original-Date: Sun, 7 Dec 2003 01:34:31 -0500 (EST) X-List-Received-Date: Sun, 07 Dec 2003 06:34:34 -0000 On Sun, 7 Dec 2003, Peter Kostouros wrote: > I have been tracking mozilla (cvs) that terminates when linked against > libkse: basically a routine checks whether a mutex variable is locked > with a call to pthread_mutex_trylock() before it attempts to unlock it > with pthread_mutex_unlock(). The return value of pthread_mutex_trylock > is checked against EBUSY and terminates the process if it is otherwise. > In my particular scenario, pthread_mutex_trylock() returns EDEADLK: the > pthread_mutex_trylock man page does not mention EDEADLK as an error code. The man page may not mention it, and that may be a bug, but I think a pthread_mutex_trylock() on a non-recursive mutex is allowed to return EDEADLK. http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided. If a thread attempts to relock a mutex that it has already locked, an error shall be returned. If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, an error shall be returned. ... If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior. Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior. Attempting to unlock the mutex if it is not locked results in undefined behavior. The pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock(), except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call shall return immediately. If the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex is currently owned by the calling thread, the mutex lock count shall be incremented by one and the pthread_mutex_trylock() function shall immediately return success. > When the application is linked against libc_r or libthr, > pthread_mutex_trylock returns EBUSY in the scenario described above. > > I suppose my question is how do you safely (and quickly) check the state > of a mutex variable? I think you (the application) are supposed to remember whether a thread has or has not locked a mutex. By default, mutexes under FreeBSD are error checking mutexes and will return EDEADLK when a thread attempts pthread_mutex_trylock() on a mutex it already owns. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Jan 26 21:49:00 2004 Return-Path: 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 A615816A528 for ; Mon, 26 Jan 2004 21:49:00 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E7D143FE2 for ; Mon, 26 Jan 2004 19:47:01 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (sccrmhc13) with ESMTP id <2004012703170001600gm48se>; Tue, 27 Jan 2004 03:17:00 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i0R3H1Nb040876; Mon, 26 Jan 2004 22:17:01 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i0R3Gs1k040875; Mon, 26 Jan 2004 22:16:54 -0500 (EST) (envelope-from rodrigc) Date: Mon, 26 Jan 2004 22:16:54 -0500 From: Craig Rodrigues To: Julian Elischer Message-ID: <20040127031654.GA40814@crodrigues.org> References: <4011546D.9010904@intalio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 05:49:01 -0000 On Fri, Jan 23, 2004 at 03:25:19PM -0800, Julian Elischer wrote: > > > On Fri, 23 Jan 2004, Alex Boisvert wrote: > > > > > Nevermind, I discovered the kernel sysctl > > "kern.threads.max_threads_per_proc" with default value 150. I bumped > > the value to 300 and the app runs fine. (We simulate 250 clients with > > 250 connections or threads, hence the need for a large value...) > > yes, the number could be made bigger but we didn't want to make it > too easy for wildly out-of-control threadded programs to > kill the system while the threading system is still "young".. 150 is a perfectly reasonable number to start with, but I can see it could be a problem later on when KSE goes "live". Due to programming languages like Java, there are a lot of threads-happy coders out there (unfortunately). I ran into this problem a few years ago when working in a group that had a multithreaded Java server on AIX. On AIX 4.2, it would crash because the max threads per process was 256, but on AIX 4.3, the limit was 32768 and things were fine. Not pretty, but this gives you an idea of the kind of multithreaded code that is being written out there.... people may complain why their multithreaded Java apps don't work nicely on FreeBSD. :( -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Jan 26 22:45:35 2004 Return-Path: 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 B5E5216A4D4 for ; Mon, 26 Jan 2004 22:45:35 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E891F43D54 for ; Mon, 26 Jan 2004 22:45:14 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i0R6j2iw026412; Tue, 27 Jan 2004 01:45:02 -0500 (EST) Date: Tue, 27 Jan 2004 01:45:02 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Craig Rodrigues In-Reply-To: <20040127031654.GA40814@crodrigues.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:45:35 -0000 On Mon, 26 Jan 2004, Craig Rodrigues wrote: > On Fri, Jan 23, 2004 at 03:25:19PM -0800, Julian Elischer wrote: > > > > > > On Fri, 23 Jan 2004, Alex Boisvert wrote: > > > > > > > > Nevermind, I discovered the kernel sysctl > > > "kern.threads.max_threads_per_proc" with default value 150. I bumped > > > the value to 300 and the app runs fine. (We simulate 250 clients with > > > 250 connections or threads, hence the need for a large value...) > > > > yes, the number could be made bigger but we didn't want to make it > > too easy for wildly out-of-control threadded programs to > > kill the system while the threading system is still "young".. > > 150 is a perfectly reasonable number to start with, but I can see it > could be a problem later on when KSE goes "live". > Due to programming languages like Java, there are a lot > of threads-happy coders out there (unfortunately). Remember though that kern.threads.max_threads_per_proc are the number of kernel threads for the process, not the number of userland threads. Threads blocked in userland don't consume a kernel thread. On the other hand, if the threads are IO bound, they will get blocked in the kernel and consume a kernel thread. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jan 27 04:21:14 2004 Return-Path: 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 F1D8116A4CE for ; Tue, 27 Jan 2004 04:21:14 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A099443D5A for ; Tue, 27 Jan 2004 04:21:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004012712210801500kc3jfe>; Tue, 27 Jan 2004 12:21:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA88096; Tue, 27 Jan 2004 04:21:08 -0800 (PST) Date: Tue, 27 Jan 2004 04:21:07 -0800 (PST) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 12:21:15 -0000 On Tue, 27 Jan 2004, Daniel Eischen wrote: > On Mon, 26 Jan 2004, Craig Rodrigues wrote: > > > On Fri, Jan 23, 2004 at 03:25:19PM -0800, Julian Elischer wrote: > > > > > > > > > On Fri, 23 Jan 2004, Alex Boisvert wrote: > > > > > > > > > > > Nevermind, I discovered the kernel sysctl > > > > "kern.threads.max_threads_per_proc" with default value 150. I bumped > > > > the value to 300 and the app runs fine. (We simulate 250 clients with > > > > 250 connections or threads, hence the need for a large value...) > > > > > > yes, the number could be made bigger but we didn't want to make it > > > too easy for wildly out-of-control threadded programs to > > > kill the system while the threading system is still "young".. > > > > 150 is a perfectly reasonable number to start with, but I can see it > > could be a problem later on when KSE goes "live". > > Due to programming languages like Java, there are a lot > > of threads-happy coders out there (unfortunately). > > Remember though that kern.threads.max_threads_per_proc are the > number of kernel threads for the process, not the number of > userland threads. Threads blocked in userland don't consume > a kernel thread. On the other hand, if the threads are IO > bound, they will get blocked in the kernel and consume a > kernel thread. We are limitted by hardware to 8191 kernel threads on x86 but that could be a LOT of user threads.. Hmm how many 64k stacks can you fit in 2GB? hmmmm 2^16 into 2^31... well that limits us to 32k threads :-) > > -- > Dan Eischen > > From owner-freebsd-threads@FreeBSD.ORG Tue Jan 27 06:21:46 2004 Return-Path: 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 0E93516A4CF for ; Tue, 27 Jan 2004 06:21:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A584943D48 for ; Tue, 27 Jan 2004 06:21:24 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i0REL6iw024951; Tue, 27 Jan 2004 09:21:06 -0500 (EST) Date: Tue, 27 Jan 2004 09:21:06 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 14:21:46 -0000 On Tue, 27 Jan 2004, Julian Elischer wrote: > > On Tue, 27 Jan 2004, Daniel Eischen wrote: > > > On Mon, 26 Jan 2004, Craig Rodrigues wrote: > > > > > On Fri, Jan 23, 2004 at 03:25:19PM -0800, Julian Elischer wrote: > > > > > > > > > > > > On Fri, 23 Jan 2004, Alex Boisvert wrote: > > > > > > > > > > > > > > Nevermind, I discovered the kernel sysctl > > > > > "kern.threads.max_threads_per_proc" with default value 150. I bumped > > > > > the value to 300 and the app runs fine. (We simulate 250 clients with > > > > > 250 connections or threads, hence the need for a large value...) > > > > > > > > yes, the number could be made bigger but we didn't want to make it > > > > too easy for wildly out-of-control threadded programs to > > > > kill the system while the threading system is still "young".. > > > > > > 150 is a perfectly reasonable number to start with, but I can see it > > > could be a problem later on when KSE goes "live". > > > Due to programming languages like Java, there are a lot > > > of threads-happy coders out there (unfortunately). > > > > Remember though that kern.threads.max_threads_per_proc are the > > number of kernel threads for the process, not the number of > > userland threads. Threads blocked in userland don't consume > > a kernel thread. On the other hand, if the threads are IO > > bound, they will get blocked in the kernel and consume a > > kernel thread. > > We are limitted by hardware to 8191 kernel threads on x86 > but that could be a LOT of user threads.. Using libkse, you are limited to 8191 KSEs, not threads. You can have as many threads for which you have the (other) resources :) > > Hmm how many 64k stacks can you fit in 2GB? > hmmmm 2^16 into 2^31... well that limits us to 32k threads :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Jan 27 18:13:17 2004 Return-Path: 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 9FA8616A4CE for ; Tue, 27 Jan 2004 18:13:17 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC00D43D39; Tue, 27 Jan 2004 18:13:06 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i0S2CeFR070514; Tue, 27 Jan 2004 18:12:41 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <40171A1A.1070003@freebsd.org> Date: Wed, 28 Jan 2004 10:10:34 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: "maxthr" state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 02:13:17 -0000 Daniel Eischen wrote: > On Tue, 27 Jan 2004, Julian Elischer wrote: >> >>We are limitted by hardware to 8191 kernel threads on x86 >>but that could be a LOT of user threads.. > > > Using libkse, you are limited to 8191 KSEs, not threads. > You can have as many threads for which you have the (other) > resources :) > > System scope threads can only have 8191 threads or less, this because current implementing in libkse and libthr use LDT entry for TLS, if we defined a fixed entry in GDT, and introduce a syscall allow userland to set TLS, and remember it in kernel, in kernel context switch routine, we can load the TLS into the fixed GDT entry, and userland only has one GDT entry for all system scope threads, for example, we use %gs as TLS register, and all thread will have same %gs, in this way, we no longer have 8191 threads limit. David Xu From owner-freebsd-threads@FreeBSD.ORG Wed Jan 28 08:50:54 2004 Return-Path: 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 DD3DB16A4CE for ; Wed, 28 Jan 2004 08:50:54 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0AC143D5A for ; Wed, 28 Jan 2004 08:50:41 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.67.162] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 35321398; Wed, 28 Jan 2004 19:45:08 +0300 Received: from mobile.acsolutions.com (localhost [127.0.0.1]) ESMTP id i0SGoagn003779; Wed, 28 Jan 2004 19:50:38 +0300 (EAT) (envelope-from mtm@mobile.acsolutions.com) Received: (from mtm@localhost) by mobile.acsolutions.com (8.12.10/8.12.10/Submit) id i0SGoXxZ003778; Wed, 28 Jan 2004 19:50:33 +0300 (EAT) (envelope-from mtm) Date: Wed, 28 Jan 2004 19:50:32 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20040128165031.GA3461@mobile.acsolutions.com> References: <3FD245FF.3040003@melbpc.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 16:50:55 -0000 On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote: > > The man page may not mention it, and that may be a bug, but I > think a pthread_mutex_trylock() on a non-recursive mutex is allowed > to return EDEADLK. > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html > > If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error > checking shall be provided. If a thread attempts to relock a > mutex that it has already locked, an error shall be returned. > If a thread attempts to unlock a mutex that it has not locked > or a mutex which is unlocked, an error shall be returned. > > ... If you look further down in the spec you will see: The pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock(), except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call shall return immediately... Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Wed Jan 28 09:01:39 2004 Return-Path: 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 3DE9E16A4CE for ; Wed, 28 Jan 2004 09:01:39 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFF9743D58 for ; Wed, 28 Jan 2004 09:01:28 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i0SH1Riw010232; Wed, 28 Jan 2004 12:01:28 -0500 (EST) Date: Wed, 28 Jan 2004 12:01:27 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20040128165031.GA3461@mobile.acsolutions.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 17:01:39 -0000 On Wed, 28 Jan 2004, Mike Makonnen wrote: > On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote: > > > > The man page may not mention it, and that may be a bug, but I > > think a pthread_mutex_trylock() on a non-recursive mutex is allowed > > to return EDEADLK. > > > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html > > > > If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error > > checking shall be provided. If a thread attempts to relock a > > mutex that it has already locked, an error shall be returned. > > If a thread attempts to unlock a mutex that it has not locked > > or a mutex which is unlocked, an error shall be returned. > > > > ... > > If you look further down in the spec you will see: > > The pthread_mutex_trylock() function shall be equivalent to > pthread_mutex_lock(), except that if the mutex object referenced > by mutex is currently locked (by any thread, including > the current thread), the call shall return immediately... Yes, but the implementation has to use internal locks to keep the mutex in a consistent state. There is no problem here. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jan 29 01:43:42 2004 Return-Path: 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 F2A3316A4CE for ; Thu, 29 Jan 2004 01:43:41 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1691E43D1F for ; Thu, 29 Jan 2004 01:43:33 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.65.234] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 35385611; Thu, 29 Jan 2004 12:37:54 +0300 Received: from mobile.acsolutions.com (localhost [127.0.0.1]) ESMTP id i0T9hJXT002615; Thu, 29 Jan 2004 12:43:24 +0300 (EAT) (envelope-from mtm@mobile.acsolutions.com) Received: (from mtm@localhost) by mobile.acsolutions.com (8.12.10/8.12.10/Submit) id i0T8LMMX001482; Thu, 29 Jan 2004 11:21:22 +0300 (EAT) (envelope-from mtm) Date: Thu, 29 Jan 2004 11:21:22 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20040129082122.GA1439@mobile.acsolutions.com> References: <20040128165031.GA3461@mobile.acsolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 09:43:42 -0000 On Wed, Jan 28, 2004 at 12:01:27PM -0500, Daniel Eischen wrote: > On Wed, 28 Jan 2004, Mike Makonnen wrote: > > > On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote: > > > > > > The man page may not mention it, and that may be a bug, but I > > > think a pthread_mutex_trylock() on a non-recursive mutex is allowed > > > to return EDEADLK. > > > > > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html > > > > > > If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error > > > checking shall be provided. If a thread attempts to relock a > > > mutex that it has already locked, an error shall be returned. > > > If a thread attempts to unlock a mutex that it has not locked > > > or a mutex which is unlocked, an error shall be returned. > > > > > > ... > > > > If you look further down in the spec you will see: > > > > The pthread_mutex_trylock() function shall be equivalent to > > pthread_mutex_lock(), except that if the mutex object referenced > > by mutex is currently locked (by any thread, including > > the current thread), the call shall return immediately... > > Yes, but the implementation has to use internal locks to > keep the mutex in a consistent state. There is no problem > here. Apologies, I was commenting on the EDEADLK vs. EBUSY issue, not the "is an internal lock allowed to block in pthread_mutex_trylock" issue. I should have also explained better instead of just throwing out the quote. EDEADLK is returned by pthread_mutex_lock() only on error checking mutexes that would otherwise deadlock if they were not error checking. Since pthread_mutex_trylock() must return immediately whether the mutex is error-checking or not, I think for consistency sake it should return EBUSY regardless of what type of mutex it is operating on. Also, the 'ERRORS' section lists EDEADLK as a _possible_ return value only for pthread_mutex_lock(). I'm not a standards expert but I think it is permissable for an implementation to return EDEADLK from pthread_mutex_trylock(). However, I think it's better to always return EBUSY, rather than EDEADLK in some cases and EBUSY in others. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Thu Jan 29 06:06:46 2004 Return-Path: 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 B787E16A4CE for ; Thu, 29 Jan 2004 06:06:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 036BE43D1F for ; Thu, 29 Jan 2004 06:06:45 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i0TE6giw003866; Thu, 29 Jan 2004 09:06:42 -0500 (EST) Date: Thu, 29 Jan 2004 09:06:42 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Mike Makonnen In-Reply-To: <20040129082122.GA1439@mobile.acsolutions.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 14:06:46 -0000 On Thu, 29 Jan 2004, Mike Makonnen wrote: > On Wed, Jan 28, 2004 at 12:01:27PM -0500, Daniel Eischen wrote: > > On Wed, 28 Jan 2004, Mike Makonnen wrote: > > > > > On Sun, Dec 07, 2003 at 01:34:31AM -0500, Daniel Eischen wrote: > > > > > > > > The man page may not mention it, and that may be a bug, but I > > > > think a pthread_mutex_trylock() on a non-recursive mutex is allowed > > > > to return EDEADLK. > > > > > > > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_trylock.html > > > > > > > > If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error > > > > checking shall be provided. If a thread attempts to relock a > > > > mutex that it has already locked, an error shall be returned. > > > > If a thread attempts to unlock a mutex that it has not locked > > > > or a mutex which is unlocked, an error shall be returned. > > > > > > > > ... > > > > > > If you look further down in the spec you will see: > > > > > > The pthread_mutex_trylock() function shall be equivalent to > > > pthread_mutex_lock(), except that if the mutex object referenced > > > by mutex is currently locked (by any thread, including > > > the current thread), the call shall return immediately... > > > > Yes, but the implementation has to use internal locks to > > keep the mutex in a consistent state. There is no problem > > here. > > Apologies, I was commenting on the EDEADLK vs. EBUSY issue, not the "is an > internal lock allowed to block in pthread_mutex_trylock" issue. I should > have also explained better instead of just throwing out the quote. > > EDEADLK is returned by pthread_mutex_lock() only on error > checking mutexes that would otherwise deadlock if they were not error > checking. Since pthread_mutex_trylock() must return immediately whether > the mutex is error-checking or not, I think for consistency sake it should > return EBUSY regardless of what type of mutex it is operating on. Also, > the 'ERRORS' section lists EDEADLK as a _possible_ return value only for > pthread_mutex_lock(). I looked at "pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock()" and inferred that it even meant returned errors should be equivalent. > I'm not a standards expert but I think it is permissable for an > implementation to return EDEADLK from pthread_mutex_trylock(). However, > I think it's better to always return EBUSY, rather than EDEADLK in > some cases and EBUSY in others. Well, anything that relies on pthread_mutex_trylock() != EBUSY to mean that the function worked is broken (clearly 0 is the only return that means success). And if the application wants to know if the current thread has the mutex locked, then returning EBUSY doesn't tell you anything, whereas EDEADLK does. Yeah, I know, applications should keep track of which mutexes they have locked! -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Jan 29 08:12:20 2004 Return-Path: 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 C6DFB16A4CE for ; Thu, 29 Jan 2004 08:12:20 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2AE143D31 for ; Thu, 29 Jan 2004 08:12:04 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.66.193] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 35417445; Thu, 29 Jan 2004 19:06:24 +0300 Received: from mobile.acsolutions.com (localhost [127.0.0.1]) ESMTP id i0TGBt41001107; Thu, 29 Jan 2004 19:11:57 +0300 (EAT) (envelope-from mtm@mobile.acsolutions.com) Received: (from mtm@localhost) by mobile.acsolutions.com (8.12.10/8.12.10/Submit) id i0TGBrs2001106; Thu, 29 Jan 2004 19:11:53 +0300 (EAT) (envelope-from mtm) Date: Thu, 29 Jan 2004 19:11:52 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20040129161152.GA1070@mobile.acsolutions.com> References: <20040129082122.GA1439@mobile.acsolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: threads@FreeBSD.org cc: Peter Kostouros Subject: Re: pthread_mutex_trylock() should never block X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 16:12:20 -0000 On Thu, Jan 29, 2004 at 09:06:42AM -0500, Daniel Eischen wrote: > > > > EDEADLK is returned by pthread_mutex_lock() only on error > > checking mutexes that would otherwise deadlock if they were not error > > checking. Since pthread_mutex_trylock() must return immediately whether > > the mutex is error-checking or not, I think for consistency sake it should > > return EBUSY regardless of what type of mutex it is operating on. Also, > > the 'ERRORS' section lists EDEADLK as a _possible_ return value only for > > pthread_mutex_lock(). > > I looked at "pthread_mutex_trylock() function shall be equivalent to > pthread_mutex_lock()" and inferred that it even meant returned > errors should be equivalent. > > > I'm not a standards expert but I think it is permissable for an > > implementation to return EDEADLK from pthread_mutex_trylock(). However, > > I think it's better to always return EBUSY, rather than EDEADLK in > > some cases and EBUSY in others. > > Well, anything that relies on pthread_mutex_trylock() != EBUSY > to mean that the function worked is broken (clearly 0 is the > only return that means success). And if the application wants > to know if the current thread has the mutex locked, then > returning EBUSY doesn't tell you anything, whereas EDEADLK > does. Yeah, I know, applications should keep track of which > mutexes they have locked! > Agreed :-) Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Thu Jan 29 15:34:07 2004 Return-Path: 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 C26D416A4CE for ; Thu, 29 Jan 2004 15:34:07 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B5143D2F for ; Thu, 29 Jan 2004 15:34:06 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i0TNY5FR063526 for ; Thu, 29 Jan 2004 15:34:06 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <401997EE.3040102@freebsd.org> Date: Fri, 30 Jan 2004 07:31:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <20040129082122.GA1439@mobile.acsolutions.com> <20040129161152.GA1070@mobile.acsolutions.com> In-Reply-To: <20040129161152.GA1070@mobile.acsolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: ptrace_clear_single_step X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 23:34:07 -0000 Is there any reason that ptrace_clear_single_step is not needed ? I found that alpha implemented it, but not other architectures. For multiple threads, debugger need to turn off single step status for specific thread, I found gdb even hacked it to clear single step flag in %eflag registers on i386 because kernel does not provide a clean way to clear it. David Xu From owner-freebsd-threads@FreeBSD.ORG Sat Jan 31 22:13:07 2004 Return-Path: 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 BB34A16A4CF for ; Sat, 31 Jan 2004 22:13:07 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7591343D2D for ; Sat, 31 Jan 2004 22:13:06 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (sccrmhc13) with ESMTP id <20040201061305016003ub2be>; Sun, 1 Feb 2004 06:13:05 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i116CDbq006384 for ; Sun, 1 Feb 2004 01:12:13 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i116CDDA006383 for freebsd-threads@freebsd.org; Sun, 1 Feb 2004 01:12:13 -0500 (EST) (envelope-from rodrigc) Date: Sun, 1 Feb 2004 01:12:12 -0500 From: Craig Rodrigues To: freebsd-threads@freebsd.org Message-ID: <20040201061212.GA6349@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 06:13:07 -0000 Hi, I wrote the following small test program to spawn a large number of threads. ================================================================== #include #include #include #include #define NUM 100000 void *thr(void *p) { select(0, NULL, NULL, NULL, NULL); return p; } int main() { pthread_t t[NUM]; int ret=0; int i; for(i=0; ; ++i) { printf("Entering pthread_create...\n"); ret = pthread_create(&t[i], NULL, thr, NULL); printf("Left pthread_create...\n"); if( ret != 0 ) { printf("%d %s\n", ret, strerror(ret)); break; } } printf("Max threads reached at: %d\n", i); return 0; } ============================================================== If I link this program with -lthr or -lc_r, the program will terminate. If I link with -lpthread, the program seems to block in the pthread_create() call, instead of returning EAGAIN (to indicate that a new thread cannot be created due to hitting some system limit). Any ideas on this? Thanks. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Sat Jan 31 23:27:44 2004 Return-Path: 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 4789A16A4CE for ; Sat, 31 Jan 2004 23:27:44 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F9C43D31 for ; Sat, 31 Jan 2004 23:27:42 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <20040201072741013009n1g3e>; Sun, 1 Feb 2004 07:27:41 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA51542; Sat, 31 Jan 2004 23:27:40 -0800 (PST) Date: Sat, 31 Jan 2004 23:27:39 -0800 (PST) From: Julian Elischer To: Craig Rodrigues In-Reply-To: <20040201061212.GA6349@crodrigues.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 07:27:44 -0000 On Sun, 1 Feb 2004, Craig Rodrigues wrote: > Hi, > > I wrote the following small test program to spawn > a large number of threads. > > ================================================================== > > #include > #include > #include > #include > > #define NUM 100000 > > void *thr(void *p) > { > select(0, NULL, NULL, NULL, NULL); > return p; > } > > > int > main() > { > pthread_t t[NUM]; > > int ret=0; > int i; > > for(i=0; ; ++i) > { > printf("Entering pthread_create...\n"); > ret = pthread_create(&t[i], NULL, thr, NULL); > printf("Left pthread_create...\n"); > > if( ret != 0 ) { > printf("%d %s\n", ret, strerror(ret)); > break; > } > } > printf("Max threads reached at: %d\n", i); > > return 0; > } > ============================================================== > > > If I link this program with -lthr or -lc_r, the > program will terminate. Successfully? that's interesting.. libthr should theoretically b elimited to about 8000 threads.. (on x86). > > If I link with -lpthread, the program seems to > block in the pthread_create() call, instead of > returning EAGAIN (to indicate that a new thread cannot > be created due to hitting some system limit). is that what you expected? > > Any ideas on this? yes to stop processes running away and making the system unusable while we are developing the therad package we made a limit on how many threads we allow to ente the kernel at one time per process.. If you trust your program, you could over-ride the limit. see: kern.threads.max_threads_per_proc: 150 kern.threads.max_groups_per_proc: 50 Your threads are all waiting in the kernel. If you used a blocked semaphore or some other non-kernel method of blocking then you would discover that you could do more or you could allow more threads to enter the kernel at a time but that would be a poor use of resources.. it is much more efficient to keep blocked threads in userland than to block them in the kernel where they use precious kernel resources. I'm not sure but I think 'sleep()' is intecepted for example to keep the sleeping threads in userland. (I may be wrong. I don't know if Dan did that yet). BTW the limit is not on making more threads, its that the last select() REALLY blocked and did not return to the userland program to allow you to make a new thread. > > Thanks. > -- > Craig Rodrigues > http://crodrigues.org > rodrigc@crodrigues.org > _______________________________________________ > 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 Sun Feb 1 04:27:06 2004 Return-Path: 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 40BF316A4CF for ; Sun, 1 Feb 2004 04:27:06 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id E046943D46 for ; Sun, 1 Feb 2004 04:27:03 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id i11CQXgr017716; Sun, 1 Feb 2004 14:26:42 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <401CF041.1050301@he.iki.fi> Date: Sun, 01 Feb 2004 14:25:37 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 12:27:06 -0000 Julian Elischer wrote: > Your threads are all waiting in the kernel. > >If you used a blocked semaphore or some other non-kernel >method of blocking then you would discover that you could do more >or you could allow more threads to enter the kernel at a time >but that would be a poor use of resources.. it is much more > > Are you saying that using poll() and serving descriptors sequentially is significantly more resource-effective than creating thread blocked on read for each fd? Pete From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 07:06:25 2004 Return-Path: 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 6180D16A4CE for ; Sun, 1 Feb 2004 07:06:25 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73E7A43D1F for ; Sun, 1 Feb 2004 07:06:21 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11F6Eiw007866; Sun, 1 Feb 2004 10:06:14 -0500 (EST) Date: Sun, 1 Feb 2004 10:06:14 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 15:06:25 -0000 On Sat, 31 Jan 2004, Julian Elischer wrote: > > On Sun, 1 Feb 2004, Craig Rodrigues wrote: > > [ ... ] > > > > If I link this program with -lthr or -lc_r, the > > program will terminate. > > Successfully? > that's interesting.. libthr should theoretically b elimited to about > 8000 threads.. (on x86). > > > > > If I link with -lpthread, the program seems to > > block in the pthread_create() call, instead of > > returning EAGAIN (to indicate that a new thread cannot > > be created due to hitting some system limit). > > is that what you expected? The threads are created and scheduled in userland (the default is process scope threads, so there is no syscall needed to create these threads). You probably even created more than `sysctl kern.threads.max_threads_per_proc` but when the main thread got swapped out (due to quantum expiration) and the other threads were scheduled, they blocked in the kernel and _then_ the system resource limit was hit. There were no threads left for upcalls, and even if there was one left for an upcall, there's no guarantee that the library can figure out which thread to resume so that your application gets an appropriate error return. > > > > Any ideas on this? > > yes > to stop processes running away and making the system unusable while we > are developing the therad package we made a limit on how many > threads we allow to ente the kernel at one time per process.. > If you trust your program, you could over-ride the limit. > > see: > kern.threads.max_threads_per_proc: 150 > kern.threads.max_groups_per_proc: 50 > > Your threads are all waiting in the kernel. > If you used a blocked semaphore or some other non-kernel > method of blocking then you would discover that you could do more > or you could allow more threads to enter the kernel at a time > but that would be a poor use of resources.. it is much more > efficient to keep blocked threads in userland than to block them in the > kernel where they use precious kernel resources. > I'm not sure but I think 'sleep()' is intecepted for example to > keep the sleeping threads in userland. (I may be wrong. > I don't know if Dan did that yet). Yes, we did :) > BTW the limit is not on making more threads, its that the last select() > REALLY blocked and did not return to the userland program to allow you > to make a new thread. Right, what Julian said :) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 07:21:19 2004 Return-Path: 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 7946816A4CF for ; Sun, 1 Feb 2004 07:21:19 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD1C43D45 for ; Sun, 1 Feb 2004 07:21:12 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (rwcrmhc11) with ESMTP id <20040201152111013009oot9e>; Sun, 1 Feb 2004 15:21:11 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i11FL6G9002532; Sun, 1 Feb 2004 10:21:06 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i11FL5na002531; Sun, 1 Feb 2004 10:21:05 -0500 (EST) (envelope-from rodrigc) Date: Sun, 1 Feb 2004 10:21:05 -0500 From: Craig Rodrigues To: Julian Elischer Message-ID: <20040201152105.GA2370@crodrigues.org> References: <20040201061212.GA6349@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 15:21:19 -0000 On Sat, Jan 31, 2004 at 11:27:39PM -0800, Julian Elischer wrote: > On Sun, 1 Feb 2004, Craig Rodrigues wrote: > > > Hi, > > > > I wrote the following small test program to spawn > > a large number of threads. > > > > ================================================================== > > > > #include > > #include > > #include > > #include > > > > #define NUM 100000 > > > > void *thr(void *p) > > { > > select(0, NULL, NULL, NULL, NULL); > > return p; > > } > > > > > > int > > main() > > { > > pthread_t t[NUM]; > > > > int ret=0; > > int i; > > > > for(i=0; ; ++i) > > { > > printf("Entering pthread_create...\n"); > > ret = pthread_create(&t[i], NULL, thr, NULL); > > printf("Left pthread_create...\n"); > > > > if( ret != 0 ) { > > printf("%d %s\n", ret, strerror(ret)); > > break; > > } > > } > > printf("Max threads reached at: %d\n", i); > > > > return 0; > > } > > ============================================================== > > > > > > If I link this program with -lthr or -lc_r, the > > program will terminate. > > Successfully? > that's interesting.. libthr should theoretically b elimited to about > 8000 threads.. (on x86). If I link with -lthr, I get: Max threads reached at: 109 If I link with -lc_r, I get: Max threads reached at: 14118 If I link with -lpthread, I get about 161 threads created, and then pthread_create() blocks and I never get to the "Max threads" message. > > > > > > If I link with -lpthread, the program seems to > > block in the pthread_create() call, instead of > > returning EAGAIN (to indicate that a new thread cannot > > be created due to hitting some system limit). > > is that what you expected? No that is not what I expected. I expected that pthread_create() should either: - if it creates the thread successfully, return 0 - if it cannot create the thread, return EAGAIN if a resource limit is it, or EINVAL if bad parameters were passed down into the pthread_create() call I never expected that pthread_create() would block. > yes > to stop processes running away and making the system unusable while we > are developing the therad package we made a limit on how many > threads we allow to ente the kernel at one time per process.. > If you trust your program, you could over-ride the limit. > > see: > kern.threads.max_threads_per_proc: 150 > kern.threads.max_groups_per_proc: 50 Understood. Keep in mind, I am trying to "kick the tires" on libpthread, to see how it reacts on crazy corner cases. I can certainly increase the values of these sysctls, but I think that pthread_create() should not block if it hits a limit. > > Your threads are all waiting in the kernel. > If you used a blocked semaphore or some other non-kernel > method of blocking then you would discover that you could do more > or you could allow more threads to enter the kernel at a time > but that would be a poor use of resources.. it is much more > efficient to keep blocked threads in userland than to block them in the > kernel where they use precious kernel resources. > I'm not sure but I think 'sleep()' is intecepted for example to > keep the sleeping threads in userland. (I may be wrong. > I don't know if Dan did that yet). > > > BTW the limit is not on making more threads, its that the last select() > REALLY blocked and did not return to the userland program to allow you > to make a new thread. Well, this may be so, but I don't think pthread_create() should block. For kicks, I ran this code on Solaris 2.7, and pthread_create() returned EAGAIN after spawning 3399 threads. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 07:41:41 2004 Return-Path: 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 A45D316A4CE for ; Sun, 1 Feb 2004 07:41:41 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C885A43D1F for ; Sun, 1 Feb 2004 07:41:36 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.67.209] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 35661953; Sun, 01 Feb 2004 18:35:55 +0300 Received: from mobile.acs-et.com (localhost [127.0.0.1]) ESMTP id i11FcaUp002684; Sun, 1 Feb 2004 18:39:10 +0300 (EAT) (envelope-from mtm@mobile.acs-et.com) Received: (from mtm@localhost) by mobile.acs-et.com (8.12.10/8.12.10/Submit) id i11FbZGv002679; Sun, 1 Feb 2004 18:37:35 +0300 (EAT) (envelope-from mtm) Date: Sun, 1 Feb 2004 18:36:52 +0300 From: Mike Makonnen To: Craig Rodrigues Message-ID: <20040201153652.GA2637@mobile.acs-et.com> References: <20040201061212.GA6349@crodrigues.org> <20040201152105.GA2370@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040201152105.GA2370@crodrigues.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 15:41:41 -0000 On Sun, Feb 01, 2004 at 10:21:05AM -0500, Craig Rodrigues wrote: > On Sat, Jan 31, 2004 at 11:27:39PM -0800, Julian Elischer wrote: > > On Sun, 1 Feb 2004, Craig Rodrigues wrote: > > > > > > If I link this program with -lthr or -lc_r, the > > > program will terminate. > > > > Successfully? > > that's interesting.. libthr should theoretically b elimited to about > > 8000 threads.. (on x86). > > If I link with -lthr, I get: > > Max threads reached at: 109 > There was an artificial limit, which I just bumped up to the max allowable limit a few minutes ago. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:22:57 2004 Return-Path: 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 71F2516A4CE for ; Sun, 1 Feb 2004 08:22:57 -0800 (PST) Received: from enigma.barak.net.il (enigma.barak.net.il [212.150.48.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5775D43D1F for ; Sun, 1 Feb 2004 08:22:54 -0800 (PST) (envelope-from ak@freenet.co.uk) Received: from hydralisk ([62.90.149.2]) by enigma.barak.net.il e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040201162458.YWHV901.enigma@hydralisk>; Sun, 1 Feb 2004 18:24:58 +0200 From: Alex Keahan To: Daniel Eischen , Julian Elischer Date: Sun, 1 Feb 2004 18:22:01 +0200 User-Agent: KMail/1.5.1 References: In-Reply-To: Organization: Home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402011822.01724.ak@freenet.co.uk> cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 16:22:57 -0000 On Sunday 01 Feb 2004 5:06 pm, Daniel Eischen wrote: > On Sat, 31 Jan 2004, Julian Elischer wrote: > > On Sun, 1 Feb 2004, Craig Rodrigues wrote: > > [ ... ] > > > > If I link this program with -lthr or -lc_r, the > > > program will terminate. > > > > Successfully? > > that's interesting.. libthr should theoretically b elimited to about > > 8000 threads.. (on x86). > > > > > If I link with -lpthread, the program seems to > > > block in the pthread_create() call, instead of > > > returning EAGAIN (to indicate that a new thread cannot > > > be created due to hitting some system limit). > > > > is that what you expected? > > The threads are created and scheduled in userland (the default > is process scope threads, so there is no syscall needed to > create these threads). You probably even created more than > `sysctl kern.threads.max_threads_per_proc` but when the > main thread got swapped out (due to quantum expiration) > and the other threads were scheduled, they blocked in > the kernel and _then_ the system resource limit was hit. > There were no threads left for upcalls, and even if there > was one left for an upcall, there's no guarantee that the > library can figure out which thread to resume so that > your application gets an appropriate error return. Perhaps the main thread should be treated specially in this regard? It is already special with respect to other threads in that it keeps them on life support (if the main thread exits, the entire process disappears) AK From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:47:04 2004 Return-Path: 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 D091C16A4CE for ; Sun, 1 Feb 2004 08:47:04 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8896943D2F for ; Sun, 1 Feb 2004 08:47:03 -0800 (PST) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.31.45.197]) by comcast.net (sccrmhc12) with ESMTP id <2004020116470201200qe7k8e>; Sun, 1 Feb 2004 16:47:02 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.crodrigues.org [127.0.0.1])i11GkuG9003492; Sun, 1 Feb 2004 11:46:56 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i11GJxhi003376; Sun, 1 Feb 2004 11:19:59 -0500 (EST) (envelope-from rodrigc) Date: Sun, 1 Feb 2004 11:19:58 -0500 From: Craig Rodrigues To: Mike Makonnen Message-ID: <20040201161958.GA3362@crodrigues.org> References: <20040201061212.GA6349@crodrigues.org> <20040201152105.GA2370@crodrigues.org> <20040201153652.GA2637@mobile.acs-et.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040201153652.GA2637@mobile.acs-et.com> User-Agent: Mutt/1.4.1i cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 16:47:04 -0000 On Sun, Feb 01, 2004 at 06:36:52PM +0300, Mike Makonnen wrote: > > > Successfully? > > > that's interesting.. libthr should theoretically b elimited to about > > > 8000 threads.. (on x86). > > > > If I link with -lthr, I get: > > > > Max threads reached at: 109 > > > > There was an artificial limit, which I just bumped up to the max allowable > limit a few minutes ago. Yes, now if I link my test program with -lthr, I get: Max threads reached at: 8173 pthread_create() does not block for libthr, while it does for libpthread. libthr seems better behaved in this respect. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:50:22 2004 Return-Path: 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 7801916A4CE for ; Sun, 1 Feb 2004 08:50:22 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6EA743D4C for ; Sun, 1 Feb 2004 08:50:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11GoCiw004861; Sun, 1 Feb 2004 11:50:12 -0500 (EST) Date: Sun, 1 Feb 2004 11:50:12 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Craig Rodrigues In-Reply-To: <20040201152105.GA2370@crodrigues.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 16:50:22 -0000 On Sun, 1 Feb 2004, Craig Rodrigues wrote: > On Sat, Jan 31, 2004 at 11:27:39PM -0800, Julian Elischer wrote: > > > > > > If I link with -lpthread, the program seems to > > > block in the pthread_create() call, instead of > > > returning EAGAIN (to indicate that a new thread cannot > > > be created due to hitting some system limit). > > > > is that what you expected? > > > No that is not what I expected. I expected > that pthread_create() should either: > - if it creates the thread successfully, return 0 > - if it cannot create the thread, return EAGAIN > if a resource limit is it, or EINVAL if bad parameters > were passed down into the pthread_create() call > > > I never expected that pthread_create() would block. You're missing the point. pthread_create() doesn't block; you're application blocks because it has consumed the limit of kernel threads allowed. It just so happens that the only runnable thread is making a lot of calls to pthread_create(), but it could be doing anything and it would still block. #include #include #include #include #include #include static pthread_mutex_t sync_lock; static void * worker(void *arg) { pthread_mutex_lock(&sync_lock); pthread_mutex_unlock(&sync_lock); select(0, NULL, NULL, NULL, NULL); return (NULL); } int main(int argc, char** argv) { pthread_t *threads; int i, n; if (argc > 1) { n = strtoimax(argv[1], NULL, 10); printf("Using %d threads (parameter)\n", n); } else { n = 5; printf("Using %d threads (default)\n", n); } threads = (pthread_t *)malloc(sizeof(pthread_t) * n); pthread_mutex_init(&sync_lock, NULL); pthread_mutex_lock(&sync_lock); /* Create and start n threads. */ for (i = 0; i < n; i++) { if (pthread_create(&threads[i], NULL, worker, NULL) != 0) { err(1, NULL); } } /* Let the threads loose. */ printf("Created %d threads; letting them loose.\n", i); pthread_mutex_unlock(&sync_lock); sleep(10); printf("Main thread waking up after sleeping\n"); /* Join the threads. */ for (i = 0; i < n; i++) { if (pthread_join(threads[i], NULL) != 0) { err(1, NULL); } printf("Joined thread %d\n", i); } free(threads); return (0); } From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:53:19 2004 Return-Path: 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 607FD16A4CE for ; Sun, 1 Feb 2004 08:53:19 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9A243D1F for ; Sun, 1 Feb 2004 08:53:17 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id i11GrAgr019020; Sun, 1 Feb 2004 18:53:10 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <401D2EBD.2030609@he.iki.fi> Date: Sun, 01 Feb 2004 18:52:13 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20040201061212.GA6349@crodrigues.org> <20040201152105.GA2370@crodrigues.org> In-Reply-To: <20040201152105.GA2370@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 16:53:19 -0000 Craig Rodrigues wrote: >Understood. Keep in mind, I am trying to "kick the tires" >on libpthread, to see how it reacts on crazy corner cases. >I can certainly increase the values of these sysctls, >but I think that pthread_create() should not block if >it hits a limit. > > > I agree here, pthread_create() should not get blocked sitting somewhere because it would easily lead to situations where a "main" thread spawning off children is blocked and cannot report errors or pthread_join() threads that terminate because of itīs blocked. Pete From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:57:52 2004 Return-Path: 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 2402916A4CE for ; Sun, 1 Feb 2004 08:57:52 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BE043D41 for ; Sun, 1 Feb 2004 08:57:50 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11Gvkiw006736; Sun, 1 Feb 2004 11:57:46 -0500 (EST) Date: Sun, 1 Feb 2004 11:57:46 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alex Keahan In-Reply-To: <200402011822.01724.ak@freenet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 16:57:52 -0000 On Sun, 1 Feb 2004, Alex Keahan wrote: > On Sunday 01 Feb 2004 5:06 pm, Daniel Eischen wrote: > > > > The threads are created and scheduled in userland (the default > > is process scope threads, so there is no syscall needed to > > create these threads). You probably even created more than > > `sysctl kern.threads.max_threads_per_proc` but when the > > main thread got swapped out (due to quantum expiration) > > and the other threads were scheduled, they blocked in > > the kernel and _then_ the system resource limit was hit. > > There were no threads left for upcalls, and even if there > > was one left for an upcall, there's no guarantee that the > > library can figure out which thread to resume so that > > your application gets an appropriate error return. > > Perhaps the main thread should be treated specially in this > regard? It is already special with respect to other threads in > that it keeps them on life support (if the main thread exits, the > entire process disappears) That isn't true. The main thread can exit and other threads will continue to run and keep the application alive. The threads library can't guess as to which thread is "special". It could be that the main thread creates only one thread, and this thread is the thread that creates all the other threads. The main thread could block in the kernel as well. The threads library can't guess at what your applications really want. You guys are looking at the application and can infer what behavior you'd like to see, but the threads library isn't artifically intelligent. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 09:00:10 2004 Return-Path: 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 0B51416A4CE for ; Sun, 1 Feb 2004 09:00:10 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010E543D1D for ; Sun, 1 Feb 2004 09:00:09 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11H03iw007329; Sun, 1 Feb 2004 12:00:03 -0500 (EST) Date: Sun, 1 Feb 2004 12:00:03 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <401D2EBD.2030609@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 17:00:10 -0000 On Sun, 1 Feb 2004, Petri Helenius wrote: > Craig Rodrigues wrote: >=20 > >Understood. Keep in mind, I am trying to "kick the tires" > >on libpthread, to see how it reacts on crazy corner cases. > >I can certainly increase the values of these sysctls, > >but I think that pthread_create() should not block if > >it hits a limit. > > > > =20 > > > I agree here, pthread_create() should not get blocked sitting somewhere= =20 > because > it would easily lead to situations where a "main" thread spawning off=20 > children > is blocked and cannot report errors or pthread_join() threads that termin= ate > because of it=B4s blocked. Arghh. pthread_create() isn't blocking! Please see my other reply. --=20 Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 10:42:22 2004 Return-Path: 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 5674216A4CE for ; Sun, 1 Feb 2004 10:42:22 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D2C43D41 for ; Sun, 1 Feb 2004 10:42:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <200402011842070150080kste>; Sun, 1 Feb 2004 18:42:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA57215; Sun, 1 Feb 2004 10:42:06 -0800 (PST) Date: Sun, 1 Feb 2004 10:42:04 -0800 (PST) From: Julian Elischer To: Petri Helenius In-Reply-To: <401D2EBD.2030609@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 18:42:22 -0000 On Sun, 1 Feb 2004, Petri Helenius wrote: > Craig Rodrigues wrote: >=20 > >Understood. Keep in mind, I am trying to "kick the tires" > >on libpthread, to see how it reacts on crazy corner cases. > >I can certainly increase the values of these sysctls, > >but I think that pthread_create() should not block if > >it hits a limit. > > > > =20 > > > I agree here, pthread_create() should not get blocked sitting somewhere= =20 > because > it would easily lead to situations where a "main" thread spawning off=20 > children > is blocked and cannot report errors or pthread_join() threads that termin= ate > because of it=B4s blocked. >=20 pthread_create() is not blocking.. Pthread_create doesn't result in a system call. creating new threads si a purely userland activity, (well, the malloc for the thread may call sbreak, but as you are running in the thread library that might be a synchronous activity anyhow I think.. (Dan, does pthread_create() count as an entry into the thread_scheduler?) In any case if it blocked in sbreak() it would be awoken very quickly. To see what is happenning, you have to understand wow these threads work.. when a thread enters the kernel and blocks, (**) a new kernel thread is created, made runnable, and set to make an upcal back to the Userland Thread Scheduler,(UTS) so that a new thread can be scheduled to replace the one that blocked. The new kernel thread is used for the next userland thread.. If the limit on kenrel threads is reached, then at the point marked "**" above, no new thread is created, so no upcall occurs. basically it's a shell game.. every time a kernel thread blocks, we create a new one for the process to use instead, until you run out. when we just don't make one. i.e. the syscall you made still blocks, but no replacement thread is delivered to teh process to keep running. The alternative would be to make EWOULDBLOCK a possible error return for EVERY syscall.. i.e if you did a select(2) as the test program does, and you recieved an EWOULDBLOCK.. what would you think/do? Noe that this all applies ONLY to threads blocked in the kernel. you may have thousands of threads in userland, blocked on userland constructs.. they don't count. Only threads blocked while holding kernel resources. From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 11:27:17 2004 Return-Path: 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 A92A616A4CF for ; Sun, 1 Feb 2004 11:27:17 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 100E943D1D for ; Sun, 1 Feb 2004 11:26:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11JQAiw016499; Sun, 1 Feb 2004 14:26:10 -0500 (EST) Date: Sun, 1 Feb 2004 14:26:10 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 19:27:17 -0000 On Sun, 1 Feb 2004, Julian Elischer wrote: >=20 > On Sun, 1 Feb 2004, Petri Helenius wrote: >=20 > > Craig Rodrigues wrote: > >=20 > > >Understood. Keep in mind, I am trying to "kick the tires" > > >on libpthread, to see how it reacts on crazy corner cases. > > >I can certainly increase the values of these sysctls, > > >but I think that pthread_create() should not block if > > >it hits a limit. > > > > > > =20 > > > > > I agree here, pthread_create() should not get blocked sitting somewhere= =20 > > because > > it would easily lead to situations where a "main" thread spawning off= =20 > > children > > is blocked and cannot report errors or pthread_join() threads that term= inate > > because of it=B4s blocked. >=20 > pthread_create() is not blocking.. >=20 > Pthread_create doesn't result in a system call. > creating new threads si a purely userland activity, > (well, the malloc for the thread may call sbreak, but as you are running > in the thread library that might be a synchronous activity anyhow I > think.. (Dan, does pthread_create() count as an entry into the > thread_scheduler?) It can depending on whether there are other higher priority threads waiting. pthread_create() results in a couple of internal locks being taken and can be (inherently) a preemption point. > In any case if it blocked in sbreak() it would be > awoken very quickly. >=20 > To see what is happenning, you have to understand wow these threads > work.. >=20 > when a thread enters the kernel and blocks, (**) a new kernel thread is > created, made runnable, and set to make an upcal back to the Userland > Thread Scheduler,(UTS) so that a new thread can be scheduled to replace > the one that blocked. The new kernel thread is used for the next > userland thread.. If the limit on kenrel threads is reached, then at the > point marked "**" above, no new thread is created, so no upcall occurs. >=20 > basically it's a shell game.. every time a kernel thread blocks, we > create a new one for the process to use instead, until you run out. when > we just don't make one. i.e. the syscall you made still blocks, but no > replacement thread is delivered to teh process to keep running. >=20 > The alternative would be to make EWOULDBLOCK a possible error return for > EVERY syscall.. i.e if you did a select(2) as the test program does, and > you recieved an EWOULDBLOCK.. what would you think/do? >=20 > Noe that this all applies ONLY to threads blocked in the kernel. you may > have thousands of threads in userland, blocked on userland constructs.. > they don't count. Only threads blocked while holding kernel resources. And you can see this with the sample program that I included in one of my last emails. I tested it with 20000 threads and they were all created just fine, but once they were running (blocked in select()) the program quickly ran out of resources (kernel threads). --=20 Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 19:41:08 2004 Return-Path: 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 2E14B16A4CE for ; Sun, 1 Feb 2004 19:41:08 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 729F543D2F for ; Sun, 1 Feb 2004 19:41:01 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DDRC3AGG; Mon, 2 Feb 2004 11:18:24 +0800 Message-ID: <401DC6C8.6090006@freebsd.org> Date: Mon, 02 Feb 2004 11:40:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 03:41:08 -0000 Daniel Eischen wrote: >On Sat, 31 Jan 2004, Julian Elischer wrote: > > >>On Sun, 1 Feb 2004, Craig Rodrigues wrote: >> >> > [ ... ] > > >>>If I link this program with -lthr or -lc_r, the >>>program will terminate. >>> >>> >>Successfully? >>that's interesting.. libthr should theoretically b elimited to about >>8000 threads.. (on x86). >> >> >> >>>If I link with -lpthread, the program seems to >>>block in the pthread_create() call, instead of >>>returning EAGAIN (to indicate that a new thread cannot >>>be created due to hitting some system limit). >>> >>> >>is that what you expected? >> >> > >The threads are created and scheduled in userland (the default >is process scope threads, so there is no syscall needed to >create these threads). You probably even created more than >`sysctl kern.threads.max_threads_per_proc` but when the >main thread got swapped out (due to quantum expiration) >and the other threads were scheduled, they blocked in >the kernel and _then_ the system resource limit was hit. >There were no threads left for upcalls, and even if there >was one left for an upcall, there's no guarantee that the >library can figure out which thread to resume so that >your application gets an appropriate error return. > You guys are better to not bet that Scheduler Activation can run large number of threads, essential differences with libc_r is libpthread is kernel thread based, and I don't think support of large number of threads is the design goal of SA, it relies on kernel. libpthread should query the sysctl to see if a new thread should be created, and the sysctl value should be raised only. The benifit of libpthread is that it still can save some resources and implement some POSIX semantics, for example, saving a kernel thread resource if the thread sleeps in userland, fast context switch ? and POSIX SCHED_RR, SCHED_FIFO, Priority based scheduling... From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 20:04:39 2004 Return-Path: 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 542F916A4CE; Sun, 1 Feb 2004 20:04:39 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6D7A43D3F; Sun, 1 Feb 2004 20:04:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1242wiw000380; Sun, 1 Feb 2004 23:02:58 -0500 (EST) Date: Sun, 1 Feb 2004 23:02:58 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <401DC6C8.6090006@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 04:04:39 -0000 On Mon, 2 Feb 2004, David Xu wrote: > Daniel Eischen wrote: > > >The threads are created and scheduled in userland (the default > >is process scope threads, so there is no syscall needed to > >create these threads). You probably even created more than > >`sysctl kern.threads.max_threads_per_proc` but when the > >main thread got swapped out (due to quantum expiration) > >and the other threads were scheduled, they blocked in > >the kernel and _then_ the system resource limit was hit. > >There were no threads left for upcalls, and even if there > >was one left for an upcall, there's no guarantee that the > >library can figure out which thread to resume so that > >your application gets an appropriate error return. > > > > You guys are better to not bet that Scheduler Activation can run large > number of > threads, essential differences with libc_r is libpthread is kernel > thread based, and > I don't think support of large number of threads is the design goal of > SA, it relies > on kernel. libpthread should query the sysctl to see if a new thread > should be created, The sysctl only defines how many kernel threads can exist. The library doesn't know how many application threads will end up simulataneously blocked in the kernel. We could limit the number of total threads created to be no more than the sysctl, but that places an artificial limit on the number of threads that may never be reached. If you want to catch EAGAIN or some error on pthread_create(), you can always create your threads with system scope instead of process scope. You should get an error on the pthread_create when you run out of kern.threads.max_groups_per_proc. > and the sysctl value should be raised only. The benifit of libpthread is > that it still can save > some resources and implement some POSIX semantics, for example, saving a > kernel > thread resource if the thread sleeps in userland, fast context switch ? > and POSIX > SCHED_RR, SCHED_FIFO, Priority based scheduling... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 11:02:46 2004 Return-Path: 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 925E616A4CE for ; Mon, 2 Feb 2004 11:02:46 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2010743D7C for ; Mon, 2 Feb 2004 11:01:54 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i12J1dFR020584 for ; Mon, 2 Feb 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12J1dgk020577 for freebsd-threads@freebsd.org; Mon, 2 Feb 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 2 Feb 2004 11:01:39 -0800 (PST) Message-Id: <200402021901.i12J1dgk020577@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 19:02:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 12:30:16 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27A0116A4CE for ; Mon, 2 Feb 2004 12:30:16 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A313743D5E for ; Mon, 2 Feb 2004 12:30:14 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i12KUEFR038589 for ; Mon, 2 Feb 2004 12:30:14 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12KUEEo038587; Mon, 2 Feb 2004 12:30:14 -0800 (PST) (envelope-from gnats) Date: Mon, 2 Feb 2004 12:30:14 -0800 (PST) Message-Id: <200402022030.i12KUEEo038587@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: kern/52817: top(1) shows garbage for threaded processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 20:30:16 -0000 The following reply was made to PR kern/52817; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Cc: tim@robbins.dropbear.id.au Subject: Re: kern/52817: top(1) shows garbage for threaded processes Date: Mon, 2 Feb 2004 15:28:22 -0500 Hi, top now has a -H command-line flag, and an 'H' interactive option which can toggle the display of threads. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 12:38:49 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F66116A4CE; Mon, 2 Feb 2004 12:38:49 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A38643D54; Mon, 2 Feb 2004 12:38:45 -0800 (PST) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) i12KcjFR039542; Mon, 2 Feb 2004 12:38:45 -0800 (PST) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12KciGp039538; Mon, 2 Feb 2004 12:38:44 -0800 (PST) (envelope-from deischen) Date: Mon, 2 Feb 2004 12:38:44 -0800 (PST) From: Daniel Eischen Message-Id: <200402022038.i12KciGp039538@freefall.freebsd.org> To: tim@robbins.dropbear.id.au, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/52817: top(1) shows garbage for threaded processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 20:38:49 -0000 Synopsis: top(1) shows garbage for threaded processes State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Mon Feb 2 12:37:13 PST 2004 State-Changed-Why: David Xu made a kernel fix for this as well as someone adding a -H option to top to show threads. Reminded by: Craig Rodrigues http://www.freebsd.org/cgi/query-pr.cgi?pr=52817 From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 13:40:21 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D05F16A4CE for ; Mon, 2 Feb 2004 13:40:21 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CB043D58 for ; Mon, 2 Feb 2004 13:40:12 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i12LeCFR051552 for ; Mon, 2 Feb 2004 13:40:12 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12LeCsg051551; Mon, 2 Feb 2004 13:40:12 -0800 (PST) (envelope-from gnats) Date: Mon, 2 Feb 2004 13:40:12 -0800 (PST) Message-Id: <200402022140.i12LeCsg051551@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 21:40:21 -0000 The following reply was made to PR bin/31661; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@FreeBSD.org Cc: nb@ravenbrook.com, mps-staff@ravenbrook.com Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Date: Mon, 2 Feb 2004 16:39:30 -0500 Hi, I just tried your test program on FreeBSD-CURRENT. When linked with -lc_r, the output is: NSI Thread 0x0804c400 BSD Thread 0x0804cc00 Posix Thread 0x0805f000 waiting for the threads to be alive ANSI is alive: 0x0804c400 BSD is alive: 0x0804cc00 Posix is alive: 0x0805f000 waiting for the signals to be delivered ANSI: Handled 1 signal 30 pthread 0x0804c400 BSD: Handled 1 signal 31 pthread 0x0804cc00 code 0 sigcontext 0x00000000 Posix: Handled 1 signal 25 pthread 0x0805f000 info 0x00000000 context 0x00000000 When linked with -lpthread, the output is: ANSI Thread 0x08053400 BSD Thread 0x08053600 Posix Thread 0x08053800 waiting for the threads to be alive ANSI is alive: 0x08053400 BSD is alive: 0x08053600 Posix is alive: 0x08053800 waiting for the signals to be delivered ANSI: Handled 1 signal 30 pthread 0x08053400 BSD: Handled 1 signal 31 pthread 0x08053600 code 0 sigcontext 0xbfaddbe8 Posix: Handled 1 signal 25 pthread 0x08053800 info 0xbfacdb58 context 0xbfacdbe8 You mentioned that the bug is demonstrated by the fact that sigcontext and context are 0 in the last two lines of the output. This problem does not seem to exist for the new pthread library. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 13:50:25 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7088A16A4CE for ; Mon, 2 Feb 2004 13:50:25 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DC5D43D6A for ; Mon, 2 Feb 2004 13:50:17 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i12LoHFR052252 for ; Mon, 2 Feb 2004 13:50:17 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12LoHq2052250; Mon, 2 Feb 2004 13:50:17 -0800 (PST) (envelope-from gnats) Date: Mon, 2 Feb 2004 13:50:17 -0800 (PST) Message-Id: <200402022150.i12LoHq2052250@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: bin/35622: sigaltstack is missing in libc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 21:50:25 -0000 The following reply was made to PR bin/35622; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Cc: michiel.dewilde@rug.ac.be Subject: Re: bin/35622: sigaltstack is missing in libc_r Date: Mon, 2 Feb 2004 16:48:14 -0500 Hi, In FreeBSD-CURRENT, libc_r does not have a symbol for sigaltstack which overrides the symbol in libc. However, the new libpthread does have such a symbol. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 14:00:50 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A2E416A4CF for ; Mon, 2 Feb 2004 14:00:50 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A0643D55 for ; Mon, 2 Feb 2004 14:00:35 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i12M0ZFR053350 for ; Mon, 2 Feb 2004 14:00:35 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12M0ZIF053349; Mon, 2 Feb 2004 14:00:35 -0800 (PST) (envelope-from gnats) Date: Mon, 2 Feb 2004 14:00:35 -0800 (PST) Message-Id: <200402022200.i12M0ZIF053349@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Nick Barnes Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Barnes List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 22:00:50 -0000 The following reply was made to PR bin/31661; it has been noted by GNATS. From: Nick Barnes To: Craig Rodrigues Cc: freebsd-gnats-submit@FreeBSD.org, mps-staff@ravenbrook.com Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Date: Mon, 02 Feb 2004 21:50:13 +0000 At 2004-02-02 21:39:30+0000, Craig Rodrigues writes: > This problem does not seem to exist for the new pthread library. Great, thanks! I must try out -CURRENT. The underlying functionality is essential for some applications (basically anything which needs to pause other threads in order to introspect on their stacks, e.g. for garbage collection). Nick B From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 14:10:48 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC54C16A4CF for ; Mon, 2 Feb 2004 14:10:48 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB81E43D31 for ; Mon, 2 Feb 2004 14:10:20 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i12MAJFR057871 for ; Mon, 2 Feb 2004 14:10:19 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i12MAJx4057870; Mon, 2 Feb 2004 14:10:19 -0800 (PST) (envelope-from gnats) Date: Mon, 2 Feb 2004 14:10:19 -0800 (PST) Message-Id: <200402022210.i12MAJx4057870@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Craig Rodrigues Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Rodrigues List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 22:10:49 -0000 The following reply was made to PR kern/43887; it has been noted by GNATS. From: Craig Rodrigues To: freebsd-gnats-submit@freebsd.org Cc: t_fisher@163.com Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex Date: Mon, 2 Feb 2004 17:05:28 -0500 Hi, I don't think that this PR is very meaningful, and should be closed. This PR basically complains about the following code consuming too much CPU if you take out the usleep(). ===================================================================== #include #include #include int main(int argc,char** argv) { pthread_mutex_t mutex; long i,j; j =0; pthread_mutex_init(&mutex,NULL); while(1) { pthread_mutex_lock(&mutex); i = j*j; j++; pthread_mutex_unlock(&mutex); printf("i=%ld\n",i); if(usleep(800)== -1) printf("usleep fail. %s",strerror(errno)); } return 0; } ===================================================================== Well, this code isn't doing too much, except for spinning in a tight loop. I think this PR should be closed. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 14:22:48 2004 Return-Path: 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 4317E16A4CE for ; Mon, 2 Feb 2004 14:22:48 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28B6B43D31 for ; Mon, 2 Feb 2004 14:22:27 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i12MLsiw029327; Mon, 2 Feb 2004 17:21:54 -0500 (EST) Date: Mon, 2 Feb 2004 17:21:54 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Craig Rodrigues In-Reply-To: <200402022150.i12LoHq2052250@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: bin/35622: sigaltstack is missing in libc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 22:22:48 -0000 On Mon, 2 Feb 2004, Craig Rodrigues wrote: > The following reply was made to PR bin/35622; it has been noted by GNATS. > > From: Craig Rodrigues > To: freebsd-gnats-submit@freebsd.org > Cc: michiel.dewilde@rug.ac.be > Subject: Re: bin/35622: sigaltstack is missing in libc_r > Date: Mon, 2 Feb 2004 16:48:14 -0500 > > Hi, > > In FreeBSD-CURRENT, libc_r does not have a symbol > for sigaltstack which overrides the symbol in libc. libc_r was built around the 96 POSIX spec that said that use of sigaltstack in a threaded program was undefined. > However, the new libpthread does have such a symbol. The new 200x POXIC spec allows sigaltstack() so David added it to libpthread. It is mostly for threads bound to kernel scheduleable entities, and use of it otherwise is undefined. Don't tell anyone, but libpthread does allow it even for scope process threads. From owner-freebsd-threads@FreeBSD.ORG Mon Feb 2 16:09:51 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 366E816A4CE; Mon, 2 Feb 2004 16:09:51 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D35143D31; Mon, 2 Feb 2004 16:09:50 -0800 (PST) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) i1309oFR081659; Mon, 2 Feb 2004 16:09:50 -0800 (PST) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i1309nMv081655; Mon, 2 Feb 2004 16:09:49 -0800 (PST) (envelope-from deischen) Date: Mon, 2 Feb 2004 16:09:49 -0800 (PST) From: Daniel Eischen Message-Id: <200402030009.i1309nMv081655@freefall.freebsd.org> To: michiel.dewilde@rug.ac.be, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/35622: sigaltstack is missing in libc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 00:09:51 -0000 Synopsis: sigaltstack is missing in libc_r State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Mon Feb 2 16:07:13 PST 2004 State-Changed-Why: libc_r is not going to have sigaltstack(). It was modeled after the '96 POSIX spec which said that use of sigaltstack() in a threaded application was undefined. The 200x POSIX spec allows sigaltstack() for threads mapped to kernel schedulable entities and libpthread provides this. libc_r is being deprecated in favor of libpthread, so if you want sigaltstack(), use libpthread. http://www.freebsd.org/cgi/query-pr.cgi?pr=35622 From owner-freebsd-threads@FreeBSD.ORG Tue Feb 3 12:11:01 2004 Return-Path: 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 CF44E16A4CE for ; Tue, 3 Feb 2004 12:11:01 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CB2743D41 for ; Tue, 3 Feb 2004 12:10:40 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004020320103901400addo7e>; Tue, 3 Feb 2004 20:10:39 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA88430 for ; Tue, 3 Feb 2004 12:10:39 -0800 (PST) X-Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA87981 for ; Tue, 3 Feb 2004 11:34:52 -0800 (PST) X-Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 73B85564AB for ; Tue, 3 Feb 2004 11:34:45 -0800 (PST) (envelope-from owner-freebsd-current@freebsd.org) X-Received: by hub.freebsd.org (Postfix) id C3B5016A4FB; Tue, 3 Feb 2004 11:34:43 -0800 (PST) Delivered-To: julian@freebsd.org X-Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B877316A4F9; Tue, 3 Feb 2004 11:34:43 -0800 (PST) Delivered-To: freebsd-current@freebsd.org X-Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2038D16A4CE for ; Tue, 3 Feb 2004 11:34:29 -0800 (PST) X-Received: from mail.asn.net (mail.asn.net [66.235.231.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BF4C43D45 for ; Tue, 3 Feb 2004 11:34:27 -0800 (PST) (envelope-from kris-fbsdcur@asn.net) X-Received: (qmail 62464 invoked by uid 80); 3 Feb 2004 19:34:27 -0000 X-Received: from 68.3.131.72 (SquirrelMail authenticated user kgale) by mail.asn.net with HTTP; Tue, 3 Feb 2004 12:34:27 -0700 (MST) Message-ID: <54647.68.3.131.72.1075836867.squirrel@mail.asn.net> Date: Tue, 3 Feb 2004 12:34:27 -0700 (MST) From: "Kris Gale" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org ReSent-Date: Tue, 3 Feb 2004 12:10:31 -0800 (PST) Resent-From: Julian Elischer Resent-To: threads@freebsd.org ReSent-Subject: MySQL with KSE -- Unstable? ReSent-Message-ID: Subject: MySQL with KSE -- Unstable? X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 20:11:02 -0000 I've given MySQL on KSE a couple of tries in production, and I've run into a problem where threads seem to build up after an hour or so, depending on load. The first time I tried it, we were maintaining a load of about 600 threads and 300 queries/second and lasted about three hours before the thread count went through the roof and MySQL became unresponsive. The second time, we were sustaining a load of 1300 threads and 600 queries/second. This only lasted about 30 minutes. Each time, upon attempting to restart MySQL without first shutting down the web cluster that was using it, the server rebooted. I'm not sure if this was because MySQL got flooded with reconnect requests, and the machine crashed trying to start up threads that quickly. Any ideas? Has anyone else had success with MySQL on 5.2 with KSE in high-load environments? Kris Gale _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Tue Feb 3 12:34:23 2004 Return-Path: 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 4852F16A4CE; Tue, 3 Feb 2004 12:34:23 -0800 (PST) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09DB343D2F; Tue, 3 Feb 2004 12:34:21 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost [127.0.0.1]) by silver.he.iki.fi (8.12.9p2/8.11.4) with ESMTP id i13KYGW2033612; Tue, 3 Feb 2004 22:34:16 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <4020058E.1070003@he.iki.fi> Date: Tue, 03 Feb 2004 22:33:18 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Gale References: <54647.68.3.131.72.1075836867.squirrel@mail.asn.net> In-Reply-To: <54647.68.3.131.72.1075836867.squirrel@mail.asn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: MySQL with KSE -- Unstable? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 20:34:23 -0000 Kris Gale wrote: >Any ideas? Has anyone else had success with MySQL on 5.2 >with KSE in high-load environments? > > I cannot even get it to shut down gracefully after it has been running for a hour or two so I would not recommend using it for production at this time. Pete From owner-freebsd-threads@FreeBSD.ORG Tue Feb 3 13:18:57 2004 Return-Path: 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 CD91916A4CE; Tue, 3 Feb 2004 13:18:57 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A67B343D48; Tue, 3 Feb 2004 13:18:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i13LImiw022365; Tue, 3 Feb 2004 16:18:48 -0500 (EST) Date: Tue, 3 Feb 2004 16:18:48 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Kris Gale In-Reply-To: <54647.68.3.131.72.1075836867.squirrel@mail.asn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer Subject: Re: MySQL with KSE -- Unstable? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 21:18:58 -0000 On Tue, 3 Feb 2004, Kris Gale wrote: > I've given MySQL on KSE a couple of tries in production, and I've > run into a problem where threads seem to build up after an hour > or so, depending on load. > > The first time I tried it, we were maintaining a load of about 600 > threads and 300 queries/second and lasted about three hours > before the thread count went through the roof and MySQL became > unresponsive. > > The second time, we were sustaining a load of 1300 threads and > 600 queries/second. This only lasted about 30 minutes. > > Each time, upon attempting to restart MySQL without first shutting > down the web cluster that was using it, the server rebooted. > I'm not sure if this was because MySQL got flooded with reconnect > requests, and the machine crashed trying to start up threads > that quickly. > > Any ideas? Has anyone else had success with MySQL on 5.2 > with KSE in high-load environments? It would help if you could give us some way to reproduce this. How you configure/install MySQL, what scripts to run to generate the queries, etc. I've not really used MySQL too much, so don't assume I know anything ;-) Also, you may have to increase kern.threads.max_threads_per_proc if you have a lot of threads stuck in the kernel. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Feb 3 15:24:29 2004 Return-Path: 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 906C216A4CE for ; Tue, 3 Feb 2004 15:24:29 -0800 (PST) Received: from mail.asn.net (mail.asn.net [66.235.231.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B91043D39 for ; Tue, 3 Feb 2004 15:24:28 -0800 (PST) (envelope-from kris-fbsd@asn.net) Received: (qmail 69169 invoked by uid 80); 3 Feb 2004 23:24:28 -0000 Received: from 68.3.131.72 (SquirrelMail authenticated user kgale) by mail.asn.net with HTTP; Tue, 3 Feb 2004 16:24:28 -0700 (MST) Message-ID: <54817.68.3.131.72.1075850668.squirrel@mail.asn.net> Date: Tue, 3 Feb 2004 16:24:28 -0700 (MST) From: "Kris Gale" To: freebsd-threads@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: MySQL with KSE -- Unstable? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 23:24:29 -0000 --- I originally posted this to freebsd-current, but it was suggested I bring it up on this list, too. --- I've given MySQL on KSE a couple of tries in production, and I've run into a problem where threads seem to build up after an hour or so, depending on load. The first time I tried it, we were maintaining a load of about 600 threads and 300 queries/second and lasted about three hours before the thread count went through the roof and MySQL became unresponsive. The second time, we were sustaining a load of 1300 threads and 600 queries/second. This only lasted about 30 minutes. Each time, upon attempting to restart MySQL without first shutting down the web cluster that was using it, the server rebooted. I'm not sure if this was because MySQL got flooded with reconnect requests, and the machine crashed trying to start up threads that quickly. Any ideas? Has anyone else had success with MySQL on 5.2 with KSE in high-load environments? Kris Gale From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 07:37:38 2004 Return-Path: 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 EB8E316A4CE; Wed, 4 Feb 2004 07:37:38 -0800 (PST) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0635D43D31; Wed, 4 Feb 2004 07:37:37 -0800 (PST) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.30) id 1AoP5s-0006J2-82; Wed, 04 Feb 2004 16:37:36 +0100 Date: Wed, 4 Feb 2004 16:37:36 +0100 From: Kirill Ponomarew To: kde@FreeBSD.org Message-ID: <20040204153736.GA37334@voodoo.oberon.net> Mail-Followup-To: Kirill Ponomarew , kde@FreeBSD.org, freebsd-threads@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline X-NCC-Regid: de.oberon Sender: Kirill Ponomarew cc: freebsd-threads@FreeBSD.org Subject: kdelibs3 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 15:37:39 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, JFYI: 1) EAI_NODATA still presents in kdelibs3 in kdecore/kextsock.cpp 2) It does not compile without libmap.conf ../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) Fatal error 'Spinlock called when not threaded.' at line 83 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) Abort trap (core dumped) -Kirill --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAIRHAQC1G6a60JuURAmOMAJ9+ifl8NJDq5x3Y/ENdR1X2ScJHzACg6/oP 42KosEU5N8wDKV5MCkoYBcE= =m9ka -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 07:47:26 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE42916A4CE; Wed, 4 Feb 2004 07:47:26 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D0DF43D3F; Wed, 4 Feb 2004 07:47:26 -0800 (PST) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) i14FlQFR012890; Wed, 4 Feb 2004 07:47:26 -0800 (PST) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i14FlPaR012884; Wed, 4 Feb 2004 07:47:25 -0800 (PST) (envelope-from deischen) Date: Wed, 4 Feb 2004 07:47:25 -0800 (PST) From: Daniel Eischen Message-Id: <200402041547.i14FlPaR012884@freefall.freebsd.org> To: t_fisher@163.com, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 15:47:27 -0000 Synopsis: abnormal CPU useage when use pthread_mutex State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Wed Feb 4 07:45:26 PST 2004 State-Changed-Why: The resolution of the scheduling clock in libc_r is msecs since poll is used as the underlying event mechanism. Use libpthread or libthr if you desire something else. http://www.freebsd.org/cgi/query-pr.cgi?pr=43887 From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 07:51:54 2004 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDA3B16A4CF; Wed, 4 Feb 2004 07:51:54 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EAF043D1D; Wed, 4 Feb 2004 07:51:54 -0800 (PST) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (deischen@localhost [127.0.0.1]) i14FprFR013529; Wed, 4 Feb 2004 07:51:54 -0800 (PST) (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i14Fpr2m013525; Wed, 4 Feb 2004 07:51:53 -0800 (PST) (envelope-from deischen) Date: Wed, 4 Feb 2004 07:51:53 -0800 (PST) From: Daniel Eischen Message-Id: <200402041551.i14Fpr2m013525@freefall.freebsd.org> To: nb@ravenbrook.com, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 15:51:55 -0000 Synopsis: pthread_kill signal handler doesn't get sigcontext or ucontext State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Wed Feb 4 07:47:36 PST 2004 State-Changed-Why: This is written against libc_r's implementation of pthread_kill; libpthread does provide full signal handler arguments to pthread_kill. Still it iw worth noting that trying to do anything sane with a context from a pthread_kill() is probably not what you want especially for scope process threads. pthread_kill() is a simulated interrupt and the threads interrupted context is generated by the threads library -- it is not like a real signal interrupted the thread while it was running. http://www.freebsd.org/cgi/query-pr.cgi?pr=31661 From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 14:49:02 2004 Return-Path: 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 7449316A4CE; Wed, 4 Feb 2004 14:49:02 -0800 (PST) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FF143D41; Wed, 4 Feb 2004 14:48:59 -0800 (PST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) i14MmvWm068145; Wed, 4 Feb 2004 22:48:57 GMT (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id i14Mmulb058306; Wed, 4 Feb 2004 22:48:57 GMT (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Daniel Eischen In-Reply-To: <200402041551.i14Fpr2m013525@freefall.freebsd.org> from Daniel Eischen of "Wed, 04 Feb 2004 07:51:53 -0800" X-Infosys-URL: ? Date: Wed, 04 Feb 2004 22:48:56 +0000 Message-ID: <58305.1075934936@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 22:49:02 -0000 At 2004-02-04 15:51:53+0000, Daniel Eischen writes: > Still it iw worth noting that trying to do anything sane with > a context from a pthread_kill() is probably not what you want > especially for scope process threads. Thanks for this note. FYI, using the context in a handler from a pthread_kill signal is standard practice for garbage collecting threaded applications: the threads need to be paused while their stacks and registers are scanned by the garbage collector; this is done by sending signals to each thread (apart from the GC thread). The signal handler saves the thread's context, notifies the GC thread, and then waits to be awoken (e.g. with sigsuspend). What memory management implementors would really like is for thread library implementors to abstract away the messy implementation details of this and to provide something like this: int pthread_suspend(pthread_t thread, ucontext_t *uap); int pthread_resume(pthread_t thread, ucontext_t *uap); I believe that various people argued for this when the pthreads standard was being put together. But it never happened, and we have been stuck with techniques such as the one I describe. I've implemented things like it for several different garbage collectors on a number of thread libraries, pthread and otherwise, on Windows (where there _is_ SuspendThread and ResumeThread) and a number of Unixes. I will be glad to be able to support multi-threaded applications on FreeBSD - my desktop OS - as well. Nick B From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 14:56:28 2004 Return-Path: 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 37D3216A4CE; Wed, 4 Feb 2004 14:56:28 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 082A543D2F; Wed, 4 Feb 2004 14:56:06 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004020422560401600147i3e>; Wed, 4 Feb 2004 22:56:05 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA05163; Wed, 4 Feb 2004 14:56:02 -0800 (PST) Date: Wed, 4 Feb 2004 14:56:01 -0800 (PST) From: Julian Elischer To: Nick Barnes In-Reply-To: <58305.1075934936@thrush.ravenbrook.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 22:56:28 -0000 On Wed, 4 Feb 2004, Nick Barnes wrote: > At 2004-02-04 15:51:53+0000, Daniel Eischen writes: > > > Still it iw worth noting that trying to do anything sane with > > a context from a pthread_kill() is probably not what you want > > especially for scope process threads. > > Thanks for this note. FYI, using the context in a handler from a > pthread_kill signal is standard practice for garbage collecting > threaded applications: the threads need to be paused while their > stacks and registers are scanned by the garbage collector; this is > done by sending signals to each thread (apart from the GC thread). > The signal handler saves the thread's context, notifies the GC thread, > and then waits to be awoken (e.g. with sigsuspend). > > What memory management implementors would really like is for thread > library implementors to abstract away the messy implementation details > of this and to provide something like this: > > int pthread_suspend(pthread_t thread, > ucontext_t *uap); > > int pthread_resume(pthread_t thread, > ucontext_t *uap); > Hmmmm looks to me like this may be easier to achieve than to have horrible hacks depending on signal behaviour.. You could even have: "suspend_all_but_me()" which would block until all threads were suspended. threads in the kernel would return and immediatly suspend.. (an upcall would be forced for their return) Note: we already have a lot of this in the debugger suppor that david Xu is working on.. > I believe that various people argued for this when the pthreads > standard was being put together. But it never happened, and we have > been stuck with techniques such as the one I describe. I've > implemented things like it for several different garbage collectors on > a number of thread libraries, pthread and otherwise, on Windows (where > there _is_ SuspendThread and ResumeThread) and a number of Unixes. I > will be glad to be able to support multi-threaded applications on > FreeBSD - my desktop OS - as well. > > Nick B > _______________________________________________ > 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 Wed Feb 4 17:03:53 2004 Return-Path: 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 0964C16A4CE for ; Wed, 4 Feb 2004 17:03:53 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77E2043D46 for ; Wed, 4 Feb 2004 17:03:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1513hfo023818; Wed, 4 Feb 2004 20:03:44 -0500 (EST) Date: Wed, 4 Feb 2004 20:03:43 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Nick Barnes cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 01:03:53 -0000 On Wed, 4 Feb 2004, Julian Elischer wrote: > > On Wed, 4 Feb 2004, Nick Barnes wrote: > > > At 2004-02-04 15:51:53+0000, Daniel Eischen writes: > > > > > Still it iw worth noting that trying to do anything sane with > > > a context from a pthread_kill() is probably not what you want > > > especially for scope process threads. > > > > Thanks for this note. FYI, using the context in a handler from a > > pthread_kill signal is standard practice for garbage collecting > > threaded applications: the threads need to be paused while their > > stacks and registers are scanned by the garbage collector; this is > > done by sending signals to each thread (apart from the GC thread). > > The signal handler saves the thread's context, notifies the GC thread, > > and then waits to be awoken (e.g. with sigsuspend). > > > > What memory management implementors would really like is for thread > > library implementors to abstract away the messy implementation details > > of this and to provide something like this: > > > > int pthread_suspend(pthread_t thread, > > ucontext_t *uap); > > > > int pthread_resume(pthread_t thread, > > ucontext_t *uap); > > > > Hmmmm looks to me like this may be easier to achieve than > to have horrible hacks depending on signal behaviour.. > > You could even have: "suspend_all_but_me()" which would block > until all threads were suspended. > threads in the kernel would return and immediatly suspend.. > (an upcall would be forced for their return) > Note: we already have a lot of this in the debugger suppor that david Xu > is working on.. See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), and pthread_suspend_allnp(3) :-) This is what the native JDK uses for GC. > > I believe that various people argued for this when the pthreads > > standard was being put together. But it never happened, and we have > > been stuck with techniques such as the one I describe. I've > > implemented things like it for several different garbage collectors on > > a number of thread libraries, pthread and otherwise, on Windows (where > > there _is_ SuspendThread and ResumeThread) and a number of Unixes. I > > will be glad to be able to support multi-threaded applications on > > FreeBSD - my desktop OS - as well. > > -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 02:06:49 2004 Return-Path: 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 D198016A4CE for ; Thu, 5 Feb 2004 02:06:49 -0800 (PST) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E11943D1D for ; Thu, 5 Feb 2004 02:06:48 -0800 (PST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) i15A6dWm091796; Thu, 5 Feb 2004 10:06:39 GMT (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id i15A6blb061472; Thu, 5 Feb 2004 10:06:38 GMT (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Daniel Eischen In-Reply-To: from Daniel Eischen of "Wed, 04 Feb 2004 20:03:43 -0500" Date: Thu, 05 Feb 2004 10:06:37 +0000 Message-ID: <61471.1075975597@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Julian Elischer cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 10:06:49 -0000 At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), > and pthread_suspend_allnp(3) :-) This is what the native JDK uses for > GC. Way cool. Can I get the context (i.e. registers) of a suspended thread? Nick B From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 06:28:00 2004 Return-Path: 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 AF99C16A4CE for ; Thu, 5 Feb 2004 06:28:00 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0592243D1F for ; Thu, 5 Feb 2004 06:27:46 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i15ERbfo002658; Thu, 5 Feb 2004 09:27:37 -0500 (EST) Date: Thu, 5 Feb 2004 09:27:37 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Nick Barnes In-Reply-To: <61471.1075975597@thrush.ravenbrook.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 14:28:00 -0000 On Thu, 5 Feb 2004, Nick Barnes wrote: > At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > > > See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), > > and pthread_suspend_allnp(3) :-) This is what the native JDK uses for > > GC. > > Way cool. Can I get the context (i.e. registers) of a suspended thread? No, you can get the thread attributes which include the stack base and addr, see pthread_attr_get_np(3). The JDK seems to make do without getting suspended thread context. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 09:24:10 2004 Return-Path: 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 DA8B816A4CE for ; Thu, 5 Feb 2004 09:24:10 -0800 (PST) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC6A543D31 for ; Thu, 5 Feb 2004 09:24:08 -0800 (PST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) i15HO2Wm004631; Thu, 5 Feb 2004 17:24:03 GMT (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id i15HO2lb063036; Thu, 5 Feb 2004 17:24:02 GMT (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Daniel Eischen In-Reply-To: from Daniel Eischen of "Thu, 05 Feb 2004 09:27:37 -0500" Date: Thu, 05 Feb 2004 17:24:02 +0000 Message-ID: <63035.1076001842@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Julian Elischer cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 17:24:11 -0000 At 2004-02-05 14:27:37+0000, Daniel Eischen writes: > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > > > > > See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), > > > and pthread_suspend_allnp(3) :-) This is what the native JDK uses for > > > GC. > > > > Way cool. Can I get the context (i.e. registers) of a suspended thread? > > No, you can get the thread attributes which include the stack base > and addr, see pthread_attr_get_np(3). The JDK seems to make do > without getting suspended thread context. Somehow the GC must see the registers of each suspended thread, so that it can preserve any objects to which the registers point. Presumably the thread context is stored in some region which the GC treats as a root (e.g. on the thread stack, identified with pthread_attr_get_np, as you say). A GC which has more information (e.g. the IP, the SP) may be able to use more sophisticated techniques (by using compiler-generated object liveness information, or by excluding dead areas of a stack segment from consideration as roots). The limit of this is a system with close-coupled compiler, thread system, and GC, which can do "precise collection", including modifying the values of registers and stack slots. Nick B From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 12:49:46 2004 Return-Path: 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 857A016A4D6 for ; Thu, 5 Feb 2004 12:49:46 -0800 (PST) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC53343D46 for ; Thu, 5 Feb 2004 12:49:13 -0800 (PST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) i15KmkWm010454; Thu, 5 Feb 2004 20:48:46 GMT (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9/8.12.9) with ESMTP id i15Kmklb063563; Thu, 5 Feb 2004 20:48:46 GMT (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: Daniel Eischen In-Reply-To: from Daniel Eischen of "Thu, 05 Feb 2004 15:14:26 -0500" Date: Thu, 05 Feb 2004 20:48:46 +0000 Message-ID: <63562.1076014126@thrush.ravenbrook.com> Sender: nb@ravenbrook.com cc: Julian Elischer cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 20:49:46 -0000 At 2004-02-05 20:14:26+0000, Daniel Eischen writes: > I hear what you are saying, but it would seem that better > designed software would avoid the issue by keeping track > of any objects a thread has, using pthread_cleanup_push/pop, > mutexes, etc. This is an argument about the utility of garbage collection in general (or possibly about the utility of threads). That subject has been done to death many times; let's not restart it here. > FWIW, the Ada tasking run-time used by GNAT has no such need > to use pthread_suspend/resume and look at thread contexts. Fascinating. Maybe I should take a look at it. If you have a sufficiently cooperative compiler then many of these tricks are not necessary. In particular, if the stack and register management code generated by your compiler (stack frame creation and teardown, register spill, reload, stack allocation, thread context switching, etc) cooperates with the garbage collector, then there may be no need even to suspend threads (e.g. if you can guarantee that any pointer in a register is also on the stack or another object, and avoid the obvious race conditions somehow). Interpreted systems (including bytecoded languages) are also easy to make much more GC-cooperative. > I don't know too much about the native JDK (1.4) but it > seems to get by with suspend/resume and without needing to > look at the thread contexts. The older JDK 1.3 did need > to do that, though. I am certainly interested in the JDK techniques; I shall investigate further. Possibly the JDK knows where or how the thread contexts are allocated, and treats such memory as a conservative root. I guess we're about done on freebsd-threads. I'll move over to freebsd-java to ask about the JDKs. Thanks again for all your advice. Nick B From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 14:35:40 2004 Return-Path: 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 067FD16A4CE for ; Thu, 5 Feb 2004 14:35:40 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4CA43D5E for ; Thu, 5 Feb 2004 14:35:37 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i15KEQfo026482; Thu, 5 Feb 2004 15:14:26 -0500 (EST) Date: Thu, 5 Feb 2004 15:14:26 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Nick Barnes In-Reply-To: <63035.1076001842@thrush.ravenbrook.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 22:35:40 -0000 On Thu, 5 Feb 2004, Nick Barnes wrote: > At 2004-02-05 14:27:37+0000, Daniel Eischen writes: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > > > At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > > > > > > > See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3), > > > > and pthread_suspend_allnp(3) :-) This is what the native JDK uses for > > > > GC. > > > > > > Way cool. Can I get the context (i.e. registers) of a suspended thread? > > > > No, you can get the thread attributes which include the stack base > > and addr, see pthread_attr_get_np(3). The JDK seems to make do > > without getting suspended thread context. > > Somehow the GC must see the registers of each suspended thread, so > that it can preserve any objects to which the registers point. > Presumably the thread context is stored in some region which the GC > treats as a root (e.g. on the thread stack, identified with > pthread_attr_get_np, as you say). > > A GC which has more information (e.g. the IP, the SP) may be able to > use more sophisticated techniques (by using compiler-generated object > liveness information, or by excluding dead areas of a stack segment > from consideration as roots). The limit of this is a system with > close-coupled compiler, thread system, and GC, which can do "precise > collection", including modifying the values of registers and stack > slots. I hear what you are saying, but it would seem that better designed software would avoid the issue by keeping track of any objects a thread has, using pthread_cleanup_push/pop, mutexes, etc. FWIW, the Ada tasking run-time used by GNAT has no such need to use pthread_suspend/resume and look at thread contexts. I don't know too much about the native JDK (1.4) but it seems to get by with suspend/resume and without needing to look at the thread contexts. The older JDK 1.3 did need to do that, though. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 05:07:24 2004 Return-Path: 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 C92E416A4CE for ; Fri, 6 Feb 2004 05:07:24 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 011B543D2F for ; Fri, 6 Feb 2004 05:07:07 -0800 (PST) (envelope-from phantom@FreeBSD.org.ua) Received: from phantom.cris.net (phantom@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i16D80oh029882; Fri, 6 Feb 2004 15:08:00 +0200 (EET) (envelope-from phantom@FreeBSD.org.ua) Received: (from phantom@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i16D809H029881; Fri, 6 Feb 2004 15:08:00 +0200 (EET) (envelope-from phantom) Date: Fri, 6 Feb 2004 15:08:00 +0200 From: Alexey Zelkin To: freebsd-threads@FreeBSD.org Message-ID: <20040206130800.GA29843@phantom.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 4.9-STABLE i386 User-Agent: Mutt/1.5.5.1i Subject: runtime checking of thread libraries mixup X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 13:07:25 -0000 hi, Some time ago (after switch of jdk14 port to libkse as default thread library) a lot of people reported problems about strange things happened after jdk14 port upgrade. Most of these problems were related to libc_r/libkse libraries mixup (i.e. one library was linked against libc_r and another against libkse). Short term fix to them was suggestion to map (via libmap) libkse -> libc_r. Long term way is to recompile everything. This problematic time caused me to think -- why no runtime checks against this issue are present. Today I got an idea and implemented it in below patch. Unfortunately this patch is not even compile tested since my -CURRENT machine is down now, so I unable to test in action as well. But it would be nice to hear that do you think about concept and realization of this idea. Attached patch is against libc_r, but code for libpthread and libthr should be absolutely same, with small 'THIS' and 'another' values tweaking. Index: uthread_init.c =================================================================== RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v retrieving revision 1.46 diff -u -r1.46 uthread_init.c --- uthread_init.c 3 Dec 2003 06:54:40 -0000 1.46 +++ uthread_init.c 6 Feb 2004 12:58:55 -0000 @@ -64,6 +64,10 @@ #include #include #include +#ifdef CHECK_LIBRARIES_MIX +#include +#include +#endif #include "un-namespace.h" #include "libc_private.h" @@ -72,6 +76,9 @@ int __pthread_cond_wait(pthread_cond_t *, pthread_mutex_t *); int __pthread_mutex_lock(pthread_mutex_t *); int __pthread_mutex_trylock(pthread_mutex_t *); +#ifdef CHECK_LIBRARIES_MIX +static void check_libraries_mix(void); +#endif /* * All weak references used within libc should be in this table. @@ -221,6 +228,9 @@ /* Only initialise the threaded application once. */ return; +#ifdef CHECK_LIBRARIES_MIX + check_libraries_mix(); +#endif _pthread_page_size = getpagesize();; _pthread_guard_default = _pthread_page_size; sched_stack_size = 4 * _pthread_page_size; @@ -563,5 +573,37 @@ { _thread_init(); return (main(argc, argv, env)); +} +#endif + +/* + * Check if threading libraries are mixed + */ +#ifdef CHECK_LIBRARIES_MIX +static void +check_libraries_mix(void) +{ + Link_map *map; + char *another [] = { "libpthread", "libkse", "libthr" }; + char *s[80]; + int i; + +#define ANOTHERSZ (sizeof(another)/sizeof(another[0])) +#define THIS "libc_r" +#define MSG "DANGER: Thread libraries mixup: both " THIS " and %s are used\n" + + dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, &map); + while (map != NULL) { + if (strstr(map->l_name, "lib") != NULL) { + for (i = 0; i++; i < ANOTHERSZ) { + if (strstr(map->l_name, another[i])) { + snprintf(s, sizeof(s), MSG, another[i]); + __sys_write(2, s, strlen(s)); + return; + } + } + } + map = map->l_next; + } } #endif -- /* Alexey Zelkin && Independent Contractor */ /* phantom(at)FreeBSD.org && http://www.FreeBSD.org/java */ /* phantom(at)cris.net && http://www.FreeBSD.org.ua/ */ From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 06:34:17 2004 Return-Path: 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 C294216A4CE for ; Fri, 6 Feb 2004 06:34:17 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2BBD43D39 for ; Fri, 6 Feb 2004 06:34:15 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i16EYEfo010928; Fri, 6 Feb 2004 09:34:14 -0500 (EST) Date: Fri, 6 Feb 2004 09:34:14 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alexey Zelkin In-Reply-To: <20040206130800.GA29843@phantom.cris.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: runtime checking of thread libraries mixup X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 14:34:18 -0000 On Fri, 6 Feb 2004, Alexey Zelkin wrote: > hi, > > Some time ago (after switch of jdk14 port to libkse as default thread > library) a lot of people reported problems about strange things happened > after jdk14 port upgrade. Most of these problems were related to > libc_r/libkse libraries mixup (i.e. one library was linked against > libc_r and another against libkse). Short term fix to them was suggestion > to map (via libmap) libkse -> libc_r. Long term way is to recompile > everything. This problematic time caused me to think -- why no runtime > checks against this issue are present. > > Today I got an idea and implemented it in below patch. Unfortunately > this patch is not even compile tested since my -CURRENT machine is down > now, so I unable to test in action as well. But it would be nice to hear > that do you think about concept and realization of this idea. > > Attached patch is against libc_r, but code for libpthread and libthr should > be absolutely same, with small 'THIS' and 'another' values tweaking. I was working on something similar but different ;-) I added "extern int __thrlib_type" to libc/include/libc_private.h and set it to 0 in libc/stdlib/exit.c (just like __isthreaded). Then I had libc_r and libpthread check it and set it to different unique values in their versions of uthread_init.c. This didn't quite work correctly because spinlocks were still being confused between libraries (still got same spinlock errors). I think it could be fixed by adding checks to the spinlock functions but I didn't really want to added additional code to them. In the end, I thought that the spinlock error messages were just as good an indication that you had linked to multiple libraries as "you have linked to multiple thread libraries" ;-) > > Index: uthread_init.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v > retrieving revision 1.46 > diff -u -r1.46 uthread_init.c > --- uthread_init.c 3 Dec 2003 06:54:40 -0000 1.46 > +++ uthread_init.c 6 Feb 2004 12:58:55 -0000 > @@ -64,6 +64,10 @@ > #include > #include > #include > +#ifdef CHECK_LIBRARIES_MIX > +#include > +#include > +#endif > #include "un-namespace.h" > > #include "libc_private.h" > @@ -72,6 +76,9 @@ > int __pthread_cond_wait(pthread_cond_t *, pthread_mutex_t *); > int __pthread_mutex_lock(pthread_mutex_t *); > int __pthread_mutex_trylock(pthread_mutex_t *); > +#ifdef CHECK_LIBRARIES_MIX > +static void check_libraries_mix(void); > +#endif > > /* > * All weak references used within libc should be in this table. > @@ -221,6 +228,9 @@ > /* Only initialise the threaded application once. */ > return; > > +#ifdef CHECK_LIBRARIES_MIX > + check_libraries_mix(); > +#endif > _pthread_page_size = getpagesize();; > _pthread_guard_default = _pthread_page_size; > sched_stack_size = 4 * _pthread_page_size; > @@ -563,5 +573,37 @@ > { > _thread_init(); > return (main(argc, argv, env)); > +} > +#endif > + > +/* > + * Check if threading libraries are mixed > + */ > +#ifdef CHECK_LIBRARIES_MIX > +static void > +check_libraries_mix(void) > +{ > + Link_map *map; > + char *another [] = { "libpthread", "libkse", "libthr" }; > + char *s[80]; > + int i; > + > +#define ANOTHERSZ (sizeof(another)/sizeof(another[0])) > +#define THIS "libc_r" > +#define MSG "DANGER: Thread libraries mixup: both " THIS " and %s are used\n" > + > + dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, &map); > + while (map != NULL) { > + if (strstr(map->l_name, "lib") != NULL) { > + for (i = 0; i++; i < ANOTHERSZ) { > + if (strstr(map->l_name, another[i])) { > + snprintf(s, sizeof(s), MSG, another[i]); > + __sys_write(2, s, strlen(s)); > + return; > + } > + } > + } > + map = map->l_next; > + } > } > #endif > > -- > /* Alexey Zelkin && Independent Contractor */ > /* phantom(at)FreeBSD.org && http://www.FreeBSD.org/java */ > /* phantom(at)cris.net && http://www.FreeBSD.org.ua/ */ > _______________________________________________ > 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" > -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 08:57:24 2004 Return-Path: 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 5DF0816A4CE for ; Fri, 6 Feb 2004 08:57:24 -0800 (PST) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E45143D39 for ; Fri, 6 Feb 2004 08:57:21 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id i16GvK08020273; Fri, 6 Feb 2004 08:57:20 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 06 Feb 2004 08:57:20 -0800 (PST) From: John Polstra To: Daniel Eischen X-Bogosity: No, tests=bogofilter, spamicity=0.499999, version=0.14.5 cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 16:57:24 -0000 On 05-Feb-2004 Daniel Eischen wrote: > On Thu, 5 Feb 2004, Nick Barnes wrote: > >> Somehow the GC must see the registers of each suspended thread, so >> that it can preserve any objects to which the registers point. >> Presumably the thread context is stored in some region which the GC >> treats as a root (e.g. on the thread stack, identified with >> pthread_attr_get_np, as you say). >> >> A GC which has more information (e.g. the IP, the SP) may be able to >> use more sophisticated techniques (by using compiler-generated object >> liveness information, or by excluding dead areas of a stack segment >> from consideration as roots). The limit of this is a system with >> close-coupled compiler, thread system, and GC, which can do "precise >> collection", including modifying the values of registers and stack >> slots. > > I hear what you are saying, but it would seem that better > designed software would avoid the issue by keeping track > of any objects a thread has, using pthread_cleanup_push/pop, > mutexes, etc. Maybe so, but that's not a useful attitude for an OS vendor to take. An operating system is a provider of services. The services it provides had better be generally useful, or people will make other choices. Like it or not, a lot of GC systems these days are built on legacy compilers (often GCC) that are not very malleable. They can't easily be made to do the bookkeeping you're asking for. Or even if they could do that, they call into legacy libraries (such as libc) that were not compiled with such bookkeeping in mind. JDK is the exception, not the rule. It is the way it is because Sun, IBM and other companies have poured zillions of dollars into it. If FreeBSD's native threads package can't provide a way to suspend all threads except the GC thread and then read the registers of the suspended threads, then the very widely-used Boehm conservative GC package won't be usable with FreeBSD's native threads. Likewise, those limitations would make it impossible to adapt Modula-3's threads package to take advantage of FreeBSD native threads -- which would be a big win performancewise. I'm sure there are plenty of other examples. John From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 09:14:04 2004 Return-Path: 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 A5C2F16A4CE for ; Fri, 6 Feb 2004 09:14:04 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF2AB43D54 for ; Fri, 6 Feb 2004 09:14:02 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004020617122901400hlta1e>; Fri, 6 Feb 2004 17:12:29 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA29383; Fri, 6 Feb 2004 09:12:29 -0800 (PST) Date: Fri, 6 Feb 2004 09:12:27 -0800 (PST) From: Julian Elischer To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 17:14:04 -0000 On Fri, 6 Feb 2004, John Polstra wrote: > On 05-Feb-2004 Daniel Eischen wrote: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > >> Somehow the GC must see the registers of each suspended thread, so > >> that it can preserve any objects to which the registers point. > >> Presumably the thread context is stored in some region which the GC > >> treats as a root (e.g. on the thread stack, identified with > >> pthread_attr_get_np, as you say). > >> > >> A GC which has more information (e.g. the IP, the SP) may be able to > >> use more sophisticated techniques (by using compiler-generated object > >> liveness information, or by excluding dead areas of a stack segment > >> from consideration as roots). The limit of this is a system with > >> close-coupled compiler, thread system, and GC, which can do "precise > >> collection", including modifying the values of registers and stack > >> slots. > > > > I hear what you are saying, but it would seem that better > > designed software would avoid the issue by keeping track > > of any objects a thread has, using pthread_cleanup_push/pop, > > mutexes, etc. > > Maybe so, but that's not a useful attitude for an OS vendor to take. > An operating system is a provider of services. The services it > provides had better be generally useful, or people will make other > choices. > > Like it or not, a lot of GC systems these days are built on legacy > compilers (often GCC) that are not very malleable. They can't > easily be made to do the bookkeeping you're asking for. Or even if > they could do that, they call into legacy libraries (such as libc) > that were not compiled with such bookkeeping in mind. JDK is the > exception, not the rule. It is the way it is because Sun, IBM and > other companies have poured zillions of dollars into it. Dan sidestepped the question.. Of course you can find the saved state (registers) of all suspended threads. and there is an interface to suspend them as he showed.. but of course the layour of the registers is SUPPOSED to be private information (in this case known to the UTS and the kernel) > > If FreeBSD's native threads package can't provide a way to suspend > all threads except the GC thread and then read the registers of the > suspended threads, then the very widely-used Boehm conservative GC > package won't be usable with FreeBSD's native threads. Likewise, > those limitations would make it impossible to adapt Modula-3's threads > package to take advantage of FreeBSD native threads -- which would > be a big win performancewise. I'm sure there are plenty of other > examples. > > John > _______________________________________________ > 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 Fri Feb 6 10:37:00 2004 Return-Path: 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 4F8FD16A4CE for ; Fri, 6 Feb 2004 10:37:00 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A5E943D46 for ; Fri, 6 Feb 2004 10:36:58 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i16H9hfo019072; Fri, 6 Feb 2004 12:09:43 -0500 (EST) Date: Fri, 6 Feb 2004 12:09:43 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 18:37:00 -0000 On Fri, 6 Feb 2004, John Polstra wrote: > On 05-Feb-2004 Daniel Eischen wrote: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > >> Somehow the GC must see the registers of each suspended thread, so > >> that it can preserve any objects to which the registers point. > >> Presumably the thread context is stored in some region which the GC > >> treats as a root (e.g. on the thread stack, identified with > >> pthread_attr_get_np, as you say). > >> > >> A GC which has more information (e.g. the IP, the SP) may be able to > >> use more sophisticated techniques (by using compiler-generated object > >> liveness information, or by excluding dead areas of a stack segment > >> from consideration as roots). The limit of this is a system with > >> close-coupled compiler, thread system, and GC, which can do "precise > >> collection", including modifying the values of registers and stack > >> slots. > > > > I hear what you are saying, but it would seem that better > > designed software would avoid the issue by keeping track > > of any objects a thread has, using pthread_cleanup_push/pop, > > mutexes, etc. > > Maybe so, but that's not a useful attitude for an OS vendor to take. > An operating system is a provider of services. The services it > provides had better be generally useful, or people will make other > choices. > > Like it or not, a lot of GC systems these days are built on legacy > compilers (often GCC) that are not very malleable. They can't GNAT is built on GCC and uses native threads. It has been built onto GCC since 2.7.x (and probably prior). > easily be made to do the bookkeeping you're asking for. Or even if > they could do that, they call into legacy libraries (such as libc) > that were not compiled with such bookkeeping in mind. JDK is the > exception, not the rule. It is the way it is because Sun, IBM and > other companies have poured zillions of dollars into it. > > If FreeBSD's native threads package can't provide a way to suspend > all threads except the GC thread and then read the registers of the > suspended threads, then the very widely-used Boehm conservative GC > package won't be usable with FreeBSD's native threads. Likewise, To date, no-one has asked for the ability to read a suspended threads registers. With libpthread, you can get the thread context via pthread_kill() which is what the PR was written against. I don't know whether you can do anything useful with that context since it can be made via signalcontext(libc). > those limitations would make it impossible to adapt Modula-3's threads > package to take advantage of FreeBSD native threads -- which would > be a big win performancewise. I'm sure there are plenty of other > examples. Well, we are implementing POSIX API's so if there is an existing standard for pthread_get_suspended_thread_context(), we'll add it. Or if there is some de-facto standard that other vendors seem to be implementing we can do that. I've even made the offer to the -java folks to add whatever they need to get the JDK to work, and so far all they really needed was suspend/resume and a way to get thread attributes (stack). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 11:26:23 2004 Return-Path: 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 B1DEF16A4DC for ; Fri, 6 Feb 2004 11:26:23 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D9A43D72 for ; Fri, 6 Feb 2004 11:25:54 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i16JPYfo023362; Fri, 6 Feb 2004 14:25:34 -0500 (EST) Date: Fri, 6 Feb 2004 14:25:34 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 19:26:23 -0000 On Fri, 6 Feb 2004, Daniel Eischen wrote: > > Well, we are implementing POSIX API's so if there is an existing > standard for pthread_get_suspended_thread_context(), we'll add it. > Or if there is some de-facto standard that other vendors seem > to be implementing we can do that. I've even made the offer to > the -java folks to add whatever they need to get the JDK to > work, and so far all they really needed was suspend/resume > and a way to get thread attributes (stack). One more take on this... With libpthread (and libthr), threads can be blocked in the kernel and the libraries don't currently have any way to get to their registers. And with libthr and scope system threads in libpthread, threads can be running outside the current threads scheduling domain. Suspension in those cases doesn't work or is not yet implemented. We would need some help from the kernel to do it properly. Plus even if you suspend a thread in the kernel, you still don't have access to its registers so the kernel would also have to provide a way to get them. The libraries might be able to use a special signal to interrupt those threads, then their contexts would be available. But the application could always do the same (and it seems from the PR that is the case in this instance). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 12:37:08 2004 Return-Path: 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 89F2316A4CE for ; Fri, 6 Feb 2004 12:37:08 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B52D843D69 for ; Fri, 6 Feb 2004 12:36:44 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 60ADB72DBF; Fri, 6 Feb 2004 12:36:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5C48C72DB5 for ; Fri, 6 Feb 2004 12:36:43 -0800 (PST) Date: Fri, 6 Feb 2004 12:36:43 -0800 (PST) From: Doug White To: freebsd-threads@freebsd.org Message-ID: <20040206122906.N16801@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: thread mixups in kde/qt X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 20:37:08 -0000 This is a blind post, mostly for the benefit of the archives (and krion :-) ) since I ran across it in the past couple of days. If you're getting the "Spinlock called when not threaded." message, its definitely mixed libraries, usually libc_r and pthread. What may not be obvious is where they're coming from in the case of kde & qt. The qt port uses it own form of libtool called qmake. Qmake contains library link instructions for the platform. If you haven't rebuilt qmake since the pthread change, it is probably still offering -lc_r to qt, and this causes the duplicate dependency when qt gets built. For me, the kdelibs3 port trips over the dependency when it tries to run an intermediary build tool that links against qt, called dcopidl. Running it without arguments will trigger the assertion. I was able to build it with debugging last night, and looking at the backtrace tipped me off that a library dependency was to blame. In general, I've found something like this to help find where libc_r dependencies are coming from: objdump -x `ldd /path/to/bad/program | awk ' { print $3 }'` | less Look for occurances of 'libc_r', then see what library they're coming from, then rebuild the offenders. As mentioned previously, you can hack around it with libmap until you can get the older stuff rebuilt. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org