From owner-freebsd-threads@FreeBSD.ORG Wed Apr 2 23:07:55 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 9B33637B401 for ; Wed, 2 Apr 2003 23:07:55 -0800 (PST) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id D43D143F3F for ; Wed, 2 Apr 2003 23:07:54 -0800 (PST) (envelope-from winter@jurai.net) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h3377sEF018985 for ; Thu, 3 Apr 2003 02:07:54 -0500 (EST) (envelope-from winter@jurai.net) Date: Thu, 3 Apr 2003 02:07:54 -0500 (EST) From: "Matthew N. Dodd" To: freebsd-threads@freebsd.org Message-ID: <20030403020521.I18916@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: /etc/libmap.conf 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, 03 Apr 2003 07:07:55 -0000 To ease testing and transition of various POSIX threading libraries I've hacked RTLD to read a config file that will map requests for one library to another. ie: # Map From Map To libc_r.so.5 libthr.so.1 libc_r.so libthr.so libthr.so.1 libthr.so.1 libthr.so libthr.so ftp://ftp.jurai.net/users/winter/patches/libmap.patch Enjoy. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 01:40:31 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 B13C137B401 for ; Thu, 3 Apr 2003 01:40:31 -0800 (PST) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA2D43F75 for ; Thu, 3 Apr 2003 01:40:31 -0800 (PST) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.9/8.12.9) with ESMTP id h339eUEF023144 for ; Thu, 3 Apr 2003 04:40:30 -0500 (EST) (envelope-from mdodd@FreeBSD.ORG) Date: Thu, 3 Apr 2003 04:40:30 -0500 (EST) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: freebsd-threads@FreeBSD.ORG In-Reply-To: <20030403020521.I18916@sasami.jurai.net> Message-ID: <20030403043640.J18916@sasami.jurai.net> References: <20030403020521.I18916@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: /etc/libmap.conf 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, 03 Apr 2003 09:40:32 -0000 On Thu, 3 Apr 2003, Matthew N. Dodd wrote: > ftp://ftp.jurai.net/users/winter/patches/libmap.patch I've just updated this patch to support constrained mappings: # libc_r.so.5 libthr.so.1 # map all [/usr/local/bin/mplayer] # map specific libc_r.so.5 libc_r.so.5 ... etc. Default entries must be listed first. If you run things out of your path you'll need to provide two entries: [foo] libbar.so.1 libbaz.so.1 [/usr/bin/foo] libbar.so.1 libbaz.so.1 I'm open to suggestions on how to specify that a constrained match should specify that it wants to have basename() run against candidates. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 12:35:57 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 98A9037B405 for ; Thu, 3 Apr 2003 12:35:57 -0800 (PST) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF8A43F93 for ; Thu, 3 Apr 2003 12:35:55 -0800 (PST) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h33Klkq02986 for ; Thu, 3 Apr 2003 15:47:46 -0500 (EST) (envelope-from geoff@speicher.org) Date: Thu, 3 Apr 2003 15:47:46 -0500 (EST) From: "Geoffrey C. Speicher" To: freebsd-threads@FreeBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 1:N threading 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, 03 Apr 2003 20:35:57 -0000 OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N threading (KSE). Each model has its own merit depending on the application. However, it would still be nice if the 1:N model didn't block the whole process when a thread blocks. Is there any reason to hold onto a pure userland implementation of 1:N? Can libc_r be implemented in terms of KSE? Geoff From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 12:55:13 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 1E01037B404 for ; Thu, 3 Apr 2003 12:55:13 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFABC43FB1 for ; Thu, 3 Apr 2003 12:55:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 99A882A8A5; Thu, 3 Apr 2003 12:55:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Geoffrey C. Speicher" In-Reply-To: Date: Thu, 03 Apr 2003 12:55:12 -0800 From: Peter Wemm Message-Id: <20030403205512.99A882A8A5@canning.wemm.org> cc: freebsd-threads@FreeBSD.ORG Subject: Re: 1:N threading 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, 03 Apr 2003 20:55:13 -0000 "Geoffrey C. Speicher" wrote: > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > threading (KSE). Each model has its own merit depending on the > application. > > However, it would still be nice if the 1:N model didn't block the whole > process when a thread blocks. Is there any reason to hold onto a pure > userland implementation of 1:N? Can libc_r be implemented in terms of > KSE? It probably could be extended to recover context when it blocks, but by the time you go that far you may as well just remove the select() wrappers and use the context recovery in the default case. And then you're most of the way to libkse anyway, the main remaining difference would be to allow more than one execution point at a time. FWIW, libkse has got large chunks of libc_r in it. So has libthr. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 12:56:57 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 DC01C37B401 for ; Thu, 3 Apr 2003 12:56:57 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B97343F3F for ; Thu, 3 Apr 2003 12:56:57 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h33KutBg010243; Thu, 3 Apr 2003 15:56:55 -0500 (EST) Received: from localhost (eischen@localhost)h33KutHG010240; Thu, 3 Apr 2003 15:56:55 -0500 (EST) Date: Thu, 3 Apr 2003 15:56:55 -0500 (EST) From: Daniel Eischen To: "Geoffrey C. Speicher" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 20:56:58 -0000 On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > threading (KSE). Each model has its own merit depending on the > application. > > However, it would still be nice if the 1:N model didn't block the whole > process when a thread blocks. Is there any reason to hold onto a pure ^ in the kernel. > userland implementation of 1:N? Can libc_r be implemented in terms of > KSE? Libc_r will go bye-bye. The KSE library will give you 1:N as long as you don't use pthread_setconcurrency() and don't create any PTHREAD_SCOPE_PROCESS threads. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 13:14:30 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 EFD5437B401 for ; Thu, 3 Apr 2003 13:14:30 -0800 (PST) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id A40FF43FAF for ; Thu, 3 Apr 2003 13:14:29 -0800 (PST) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h33LQIS03067; Thu, 3 Apr 2003 16:26:18 -0500 (EST) (envelope-from geoff@speicher.org) Date: Thu, 3 Apr 2003 16:26:18 -0500 (EST) From: "Geoffrey C. Speicher" 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: 1:N threading 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, 03 Apr 2003 21:14:31 -0000 On Thu, 3 Apr 2003, Daniel Eischen wrote: > On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > > > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > > threading (KSE). Each model has its own merit depending on the > > application. > > > > However, it would still be nice if the 1:N model didn't block the whole > > process when a thread blocks. Is there any reason to hold onto a pure > ^ in the kernel. > > > userland implementation of 1:N? Can libc_r be implemented in terms of > > KSE? > > Libc_r will go bye-bye. The KSE library will give you 1:N > as long as you don't use pthread_setconcurrency() and don't > create any PTHREAD_SCOPE_PROCESS threads. Doh. I guess it would help if I reviewed the KSE project goals, hmm? :/ I lost sight of that whole userland piece of the project somewhere during last year... too much drinking, I guess. Thanks. Geoff From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 14:39:45 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 E63B637B401 for ; Thu, 3 Apr 2003 14:39:45 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4511943FA3 for ; Thu, 3 Apr 2003 14:39:45 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0138.cvx21-bradley.dialup.earthlink.net ([209.179.192.138] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 191DMq-0004hc-00; Thu, 03 Apr 2003 14:39:33 -0800 Message-ID: <3E8CB7D3.A4B3CBF7@mindspring.com> Date: Thu, 03 Apr 2003 14:38:11 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4618e752b7c97411a3326757fdd7254b5548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: "Geoffrey C. Speicher" cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 22:39:46 -0000 Daniel Eischen wrote: > Libc_r will go bye-bye. The KSE library will give you 1:N > as long as you don't use pthread_setconcurrency() and don't > create any PTHREAD_SCOPE_PROCESS threads. I think that maybe you need to get over the "fear factor" here. Specifically, it's probably time to commit a "libkse", the same way that Jeff committed a "libthr", so that it doesn't directly replace "libc_r", and leave people hanging over a cliff if it has a bug. Better to take an approach that doesn't piss people off, but gets the code to a wider audience. Is this a possibility? The only thing that seems screwed up is the signals processing. Jeff's code panic's the system with a lock order reversal on exit processing, under some circumstances, but it's tolerated because it didn't outright replace "libc_r", and offer an alternative to "conservative" -CURRENT users. -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 15:22:25 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 43F1737B405 for ; Thu, 3 Apr 2003 15:22:25 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F54143F93 for ; Thu, 3 Apr 2003 15:22:24 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h33NMNBg000113; Thu, 3 Apr 2003 18:22:23 -0500 (EST) Received: from localhost (eischen@localhost)h33NMN6T000110; Thu, 3 Apr 2003 18:22:23 -0500 (EST) Date: Thu, 3 Apr 2003 18:22:23 -0500 (EST) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3E8CB7D3.A4B3CBF7@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Geoffrey C. Speicher" cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 23:22:25 -0000 On Thu, 3 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > Libc_r will go bye-bye. The KSE library will give you 1:N > > as long as you don't use pthread_setconcurrency() and don't > > create any PTHREAD_SCOPE_PROCESS threads. > > > I think that maybe you need to get over the "fear factor" here. > > Specifically, it's probably time to commit a "libkse", the same > way that Jeff committed a "libthr", so that it doesn't directly > replace "libc_r", and leave people hanging over a cliff if it > has a bug. There already is a "libkse" committed. It's in src/lib/libpthread. It sorta works from what I understand (so far I've only run my locally modified version). My changes haven't been committed yet because I at least want to get it to the point that it can run most of the test programs (to be on-par with the current libpthread). David, Julian, and myself are working out some issues with signals, but that isn't currently hindering my progress. I am getting closer to be able to run some of the more complicated test programs. > Better to take an approach that doesn't piss people off, but gets > the code to a wider audience. > > Is this a possibility? The only thing that seems screwed up is > the signals processing. Jeff's code panic's the system with a > lock order reversal on exit processing, under some circumstances, > but it's tolerated because it didn't outright replace "libc_r", > and offer an alternative to "conservative" -CURRENT users. The patches are available: http://people.freebsd.org/~deischen/libpthread.diffs FYI, since this is a new mailing list, the above changes are meant to give libpthread M:N capability. I don't need testers; I have enough bugs that I know about to fix. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 15:35:42 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 68EC737B401 for ; Thu, 3 Apr 2003 15:35:42 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A4F43F75 for ; Thu, 3 Apr 2003 15:35:42 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id F02592A8A7; Thu, 3 Apr 2003 15:35:41 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Date: Thu, 03 Apr 2003 15:35:41 -0800 From: Peter Wemm Message-Id: <20030403233541.F02592A8A7@canning.wemm.org> cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 23:35:42 -0000 Daniel Eischen wrote: > The patches are available: > > http://people.freebsd.org/~deischen/libpthread.diffs > > FYI, since this is a new mailing list, the above changes > are meant to give libpthread M:N capability. > > I don't need testers; I have enough bugs that I know about > to fix. + __asm__("movl %%gs, %0" : "=r" (id)); + id >>= 3; + if (id - NLDT < 0) There is a problem here, NLDT is kernel private and changes depending on things like whether SMP is enabled or what the maximum number of cpus is. You're trying to find if its a local or global selector, right? What you really want is bit 2 which tells you which it is. #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ #define SEL_LDT 4 /* local descriptor table */ Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 15:44:59 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 8101D37B401 for ; Thu, 3 Apr 2003 15:44:59 -0800 (PST) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id F19E343FAF for ; Thu, 3 Apr 2003 15:44:57 -0800 (PST) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h33NuiJ03361; Thu, 3 Apr 2003 18:56:45 -0500 (EST) (envelope-from geoff@speicher.org) Date: Thu, 3 Apr 2003 18:56:44 -0500 (EST) From: "Geoffrey C. Speicher" To: Terry Lambert In-Reply-To: <3E8CB7D3.A4B3CBF7@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 23:44:59 -0000 On Thu, 3 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > Libc_r will go bye-bye. The KSE library will give you 1:N > > as long as you don't use pthread_setconcurrency() and don't > > create any PTHREAD_SCOPE_PROCESS threads. > > > I think that maybe you need to get over the "fear factor" here. > > Specifically, it's probably time to commit a "libkse", the same > way that Jeff committed a "libthr", so that it doesn't directly > replace "libc_r", and leave people hanging over a cliff if it > has a bug. I was thinking that would be nice too, until I visited http://www.freebsd.org/kse/ and found it was already done. To quote: In order to use KSE in an application, you need to link it against libpthreads, which is not built by default. To build and install it on your system, either run make all install from /usr/src/lib/libpthread (if you have sources installed on your system), or check out the libpthread and libc modules from CVS. You don't need to rebuild libc, but the libpthread makefiles refer to parts of the libc sources. Linking an application against libpthread is straighforward. In its makefiles, change the -pthread option to -lpthread and relink. Alternatively, you can copy libpthread.so on top of libc_r.so, but this is not recommended until libpthread.so becomes a bit more stable. I'm going to give it a whirl since Jeff's overnight commits to libthr make my system reboot every time I run mozilla. How much worse can libpthread be? :) *tinker, tinker* Geoff From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 15:49:41 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 1531037B401 for ; Thu, 3 Apr 2003 15:49:41 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D51A43FA3 for ; Thu, 3 Apr 2003 15:49:40 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.6p2/8.12.3) with ESMTP id h33NnbZu052821 for ; Thu, 3 Apr 2003 15:49:37 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 15:49:39 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h33NndNB086716; Thu, 3 Apr 2003 15:49:39 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h33NnWxo086715; Thu, 3 Apr 2003 15:49:32 -0800 (PST) Date: Thu, 3 Apr 2003 15:49:32 -0800 From: Gordon Tetlow To: "Geoffrey C. Speicher" Message-ID: <20030403234932.GW69100@roark.gnf.org> References: <3E8CB7D3.A4B3CBF7@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+VeMz1SRxFChf6vr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 03 Apr 2003 23:49:39.0767 (UTC) FILETIME=[B0E5F470:01C2FA3B] cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 03 Apr 2003 23:49:41 -0000 --+VeMz1SRxFChf6vr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2003 at 06:56:44PM -0500, Geoffrey C. Speicher wrote: >=20 > I'm going to give it a whirl since Jeff's overnight commits to > libthr make my system reboot every time I run mozilla. How much > worse can libpthread be? :) I had a similar problem. There was a recent commit to fix a buffer overflow. Give it a try. -gordon --+VeMz1SRxFChf6vr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+jMiMRu2t9DV9ZfsRAg0RAJ0RuSMDU7tvybGVuJ/XdFob2IIvbACfYfKl fy0GZG4c1gBkidGQ+W50oNg= =ra3E -----END PGP SIGNATURE----- --+VeMz1SRxFChf6vr-- From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 15:51:38 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 069FE37B401 for ; Thu, 3 Apr 2003 15:51:38 -0800 (PST) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id C476E43FA3 for ; Thu, 3 Apr 2003 15:51:33 -0800 (PST) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h3403Pj03380; Thu, 3 Apr 2003 19:03:25 -0500 (EST) (envelope-from geoff@speicher.org) Date: Thu, 3 Apr 2003 19:03:25 -0500 (EST) From: "Geoffrey C. Speicher" 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: 1:N threading 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, 03 Apr 2003 23:51:38 -0000 On Thu, 3 Apr 2003, Daniel Eischen wrote: > On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > > > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > > threading (KSE). Each model has its own merit depending on the > > application. > > > > However, it would still be nice if the 1:N model didn't block the whole > > process when a thread blocks. Is there any reason to hold onto a pure > ^ in the kernel. > > > userland implementation of 1:N? Can libc_r be implemented in terms of > > KSE? > > Libc_r will go bye-bye. The KSE library will give you 1:N > as long as you don't use pthread_setconcurrency() and don't > create any PTHREAD_SCOPE_PROCESS threads. Two questions: 1. You meant PTHREAD_SCOPE_SYSTEM, right? 2. Does always using PTHREAD_SCOPE_PROCESS give 1:1 threading that would also replace libthr? Geoff From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 16:01:29 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 8999937B401 for ; Thu, 3 Apr 2003 16:01:29 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D862B43FBF for ; Thu, 3 Apr 2003 16:01:28 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3401SBg004786; Thu, 3 Apr 2003 19:01:28 -0500 (EST) Received: from localhost (eischen@localhost)h3401ReK004783; Thu, 3 Apr 2003 19:01:27 -0500 (EST) Date: Thu, 3 Apr 2003 19:01:27 -0500 (EST) From: Daniel Eischen To: "Geoffrey C. Speicher" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 00:01:29 -0000 On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > On Thu, 3 Apr 2003, Daniel Eischen wrote: > > > On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > > > > > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > > > threading (KSE). Each model has its own merit depending on the > > > application. > > > > > > However, it would still be nice if the 1:N model didn't block the whole > > > process when a thread blocks. Is there any reason to hold onto a pure > > ^ in the kernel. > > > > > userland implementation of 1:N? Can libc_r be implemented in terms of > > > KSE? > > > > Libc_r will go bye-bye. The KSE library will give you 1:N > > as long as you don't use pthread_setconcurrency() and don't > > create any PTHREAD_SCOPE_PROCESS threads. > > Two questions: > > 1. You meant PTHREAD_SCOPE_SYSTEM, right? Sorry, yes. I always seem to make that mistake. > 2. Does always using PTHREAD_SCOPE_PROCESS give 1:1 threading > that would also replace libthr? Yes, it would give the same effect. With the current KSE architecture, there is a small overhead for scope system threads, but with a few, probably minor, changes to the kernel and UTS we can get rid of that. Performance tuning comes last :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 16:07:05 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 3077B37B401; Thu, 3 Apr 2003 16:07:05 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C00543F3F; Thu, 3 Apr 2003 16:07:04 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.6p2/8.12.3) with ESMTP id h34071Zu052935; Thu, 3 Apr 2003 16:07:01 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 16:07:03 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h34073NB087037; Thu, 3 Apr 2003 16:07:03 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h34073tL087036; Thu, 3 Apr 2003 16:07:03 -0800 (PST) Date: Thu, 3 Apr 2003 16:07:03 -0800 From: Gordon Tetlow To: threads@freebsd.org, current@freebsd.org Message-ID: <20030404000703.GX69100@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PyWBHxIrsGpYNMFw" Content-Disposition: inline User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 04 Apr 2003 00:07:04.0014 (UTC) FILETIME=[1F5166E0:01C2FA3E] Subject: Yet another libthr crash 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, 04 Apr 2003 00:07:05 -0000 --PyWBHxIrsGpYNMFw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm just hitting all the fun bugs today..... No core dump from this one. Privoxy seems to be a good app to test multiple io threads and is simple enough to be debug. Here's what I got this time: $ /usr/local/sbin/privoxy --no-daemon /usr/local/etc/privoxy/config Apr 03 15:50:49 Privoxy(134709248) Info: loading configuration file '/usr/local/etc/privoxy/config': ... Apr 03 15:51:09 Privoxy(134922240) Request: www.dilbert.com/images/ffffff_dot.gif Apr 03 15:51:09 Privoxy(134922240) Error: could not resolve hostname www.dilbert.com Apr 03 15:51:09 Privoxy(134925312) Request: www.dilbert.com/comics/dilbert/images/dilbertawards_250x50.gif Apr 03 15:51:09 Privoxy(134992896) Request: www.dilbert.com/comics/dilbert/images/current_features_bullet.gif gif Apr 03 15:51:09 Privoxy(134992896) Request: www.dilbert.com/comics/dilbert/images/current_features_bullApr 03 15:51:09 Privoxy(134929408) Request: www.dilbert.com/comics/dilbert/images/current_features_border_righFatal error 'Illegal call from signal handler' at line 1542 in file /local/usr.src/lib/libthr/thread/thr_mutex.c (errno = 2) $ Kind of odd how the requests are interleaved. And then it seems to have died somewhere in thr_mutex.c::mutex_queue_enq(). -gordon --PyWBHxIrsGpYNMFw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+jMynRu2t9DV9ZfsRAgKPAKCZK/YTWkOnBqN/L58YP220YWSICACfW9v5 eThRA2AGv2+qvw/MrJOncKo= =XxFc -----END PGP SIGNATURE----- --PyWBHxIrsGpYNMFw-- From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 16:26:22 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 ABA0C37B401 for ; Thu, 3 Apr 2003 16:26:22 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 077F443F93 for ; Thu, 3 Apr 2003 16:26:22 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h340QLBg007669; Thu, 3 Apr 2003 19:26:21 -0500 (EST) Received: from localhost (eischen@localhost)h340QKET007665; Thu, 3 Apr 2003 19:26:20 -0500 (EST) Date: Thu, 3 Apr 2003 19:26:20 -0500 (EST) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030403233541.F02592A8A7@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 00:26:23 -0000 On Thu, 3 Apr 2003, Peter Wemm wrote: > Daniel Eischen wrote: > > > The patches are available: > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > FYI, since this is a new mailing list, the above changes > > are meant to give libpthread M:N capability. > > > > I don't need testers; I have enough bugs that I know about > > to fix. > > + __asm__("movl %%gs, %0" : "=r" (id)); > + id >>= 3; > + if (id - NLDT < 0) > > There is a problem here, NLDT is kernel private and changes depending on > things like whether SMP is enabled or what the maximum number of cpus > is. > > You're trying to find if its a local or global selector, right? > What you really want is bit 2 which tells you which it is. > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > #define SEL_LDT 4 /* local descriptor table */ OK, but if NLDT is kernel private, how do can I know what LDTs I can use as local? (*) (*) The only thing I know about LDTs came from an Intel 486 architecture manual. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 16:32:16 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 7810737B401; Thu, 3 Apr 2003 16:32:16 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB96643FB1; Thu, 3 Apr 2003 16:32:13 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h340W7100206; Thu, 3 Apr 2003 16:32:07 -0800 (PST) Message-ID: <3E8CD287.2010408@isi.edu> Date: Thu, 03 Apr 2003 16:32:07 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030402 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Gordon Tetlow References: <20030404000703.GX69100@roark.gnf.org> In-Reply-To: <20030404000703.GX69100@roark.gnf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050708030505060502020409" cc: threads@freebsd.org cc: current@freebsd.org Subject: Re: Yet another libthr crash 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, 04 Apr 2003 00:32:16 -0000 This is a cryptographically signed message in MIME format. --------------ms050708030505060502020409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gordon Tetlow wrote: > > No core dump from this one. Privoxy seems to be a good app to test > multiple io threads and is simple enough to be debug. The source is also pretty Linux-centric, so some issues you finds may be related to that. (But I am all for fixing privoxy on -current, so I can start using it instead of guidescope, which fails to reap its kids due to some linux emulator change - see "zombies from linux binaries" thread on -current, circa 10/01/02.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms050708030505060502020409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDQwNDAwMzIwN1owIwYJKoZIhvcNAQkEMRYEFFl6QLt+eKGAuWmnVk9b RnTph2itMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAYJNx0RH/u1MwndxgD8sbW/RZYm99bL1xXXPf x3JcVlwB8FcLqjSRxWESShT7zILiFtAMYZ89hVC+KitL9TkQpj9G8A5tSwCpbeBZ+FGrdhRr dCouib+noTjjAELyc0DdnwyWpllwwmuS57TATFx6a1L8Mzbf2GZyTzGNSnvqMNVBYynJPGfK KbaUqE0/pKbFM7niatM5ts1yrcGyHFF1/cv4ZRddJg9W93SI2DQC/fI4+gIwMxqSQPfhTPBS rn49XE0IPqsULw2MOoGXBjVHLSjdPKu2+qZynn1uhSe08UCdZg17PDW8h8Nfp4pazv59gpMR Sui3ZTktx2FRw9J4EQAAAAAAAA== --------------ms050708030505060502020409-- From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 18:22:18 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 01C6637B412 for ; Thu, 3 Apr 2003 18:22:18 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08AAF43F85 for ; Thu, 3 Apr 2003 18:22:17 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h342TCxS055611; Thu, 3 Apr 2003 21:29:12 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h342TCRU055610; Thu, 3 Apr 2003 21:29:12 -0500 (EST) Date: Thu, 3 Apr 2003 21:29:11 -0500 From: Jake Burkholder To: Peter Wemm Message-ID: <20030404022911.GA55016@locore.ca> References: <20030403233541.F02592A8A7@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030403233541.F02592A8A7@canning.wemm.org> User-Agent: Mutt/1.4i cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 02:22:18 -0000 Apparently, On Thu, Apr 03, 2003 at 03:35:41PM -0800, Peter Wemm said words to the effect of; > Daniel Eischen wrote: > > > The patches are available: > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > FYI, since this is a new mailing list, the above changes > > are meant to give libpthread M:N capability. > > > > I don't need testers; I have enough bugs that I know about > > to fix. > > + __asm__("movl %%gs, %0" : "=r" (id)); > + id >>= 3; > + if (id - NLDT < 0) > > There is a problem here, NLDT is kernel private and changes depending on > things like whether SMP is enabled or what the maximum number of cpus > is. > > You're trying to find if its a local or global selector, right? > What you really want is bit 2 which tells you which it is. > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > #define SEL_LDT 4 /* local descriptor table */ NLDT seems to be invariant, but we should have a sysctl or something to get the first LDT entry that is unused by the kernel. Libthr uses it in order to know which entry to start at. Jake From owner-freebsd-threads@FreeBSD.ORG Thu Apr 3 18:24:19 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 F0D1937B405 for ; Thu, 3 Apr 2003 18:24:18 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id C902543F93 for ; Thu, 3 Apr 2003 18:24:15 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h342VBxS055637; Thu, 3 Apr 2003 21:31:11 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h342VB2u055636; Thu, 3 Apr 2003 21:31:11 -0500 (EST) Date: Thu, 3 Apr 2003 21:31:11 -0500 From: Jake Burkholder To: Peter Wemm Message-ID: <20030404023111.GB55016@locore.ca> References: <20030403233541.F02592A8A7@canning.wemm.org> <20030404022911.GA55016@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030404022911.GA55016@locore.ca> User-Agent: Mutt/1.4i cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 02:24:19 -0000 Apparently, On Thu, Apr 03, 2003 at 09:29:11PM -0500, Jake Burkholder said words to the effect of; > Apparently, On Thu, Apr 03, 2003 at 03:35:41PM -0800, > Peter Wemm said words to the effect of; > > > Daniel Eischen wrote: > > > > > The patches are available: > > > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > > > FYI, since this is a new mailing list, the above changes > > > are meant to give libpthread M:N capability. > > > > > > I don't need testers; I have enough bugs that I know about > > > to fix. > > > > + __asm__("movl %%gs, %0" : "=r" (id)); > > + id >>= 3; > > + if (id - NLDT < 0) > > > > There is a problem here, NLDT is kernel private and changes depending on > > things like whether SMP is enabled or what the maximum number of cpus > > is. > > > > You're trying to find if its a local or global selector, right? > > What you really want is bit 2 which tells you which it is. > > > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > > #define SEL_LDT 4 /* local descriptor table */ > > NLDT seems to be invariant, but we should have a sysctl or something to > get the first LDT entry that is unused by the kernel. Libthr uses it > in order to know which entry to start at. Actually Dan uses it for the exact same thing :) Jake From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 08:39:17 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 0B9A137B401 for ; Fri, 4 Apr 2003 08:39:17 -0800 (PST) Received: from speicher.org (sirius.speicher.org [209.74.10.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF4E43FCB for ; Fri, 4 Apr 2003 08:39:15 -0800 (PST) (envelope-from geoff@speicher.org) Received: from localhost (geoff@localhost) by speicher.org (8.11.6/8.11.6) with ESMTP id h34Gp5N05398; Fri, 4 Apr 2003 11:51:05 -0500 (EST) (envelope-from geoff@speicher.org) Date: Fri, 4 Apr 2003 11:51:05 -0500 (EST) From: "Geoffrey C. Speicher" To: Gordon Tetlow In-Reply-To: <20030403234932.GW69100@roark.gnf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 16:39:17 -0000 On Thu, 3 Apr 2003, Gordon Tetlow wrote: > On Thu, Apr 03, 2003 at 06:56:44PM -0500, Geoffrey C. Speicher wrote: > > > > I'm going to give it a whirl since Jeff's overnight commits to > > libthr make my system reboot every time I run mozilla. How much > > worse can libpthread be? :) > > I had a similar problem. There was a recent commit to fix a buffer > overflow. Give it a try. Nope, same deal. And to answer my questions about libpthread, it reboots much sooner than that. :) Geoff From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 12:03:11 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 1DEC537B40E for ; Fri, 4 Apr 2003 12:03:11 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC10A43FAF for ; Fri, 4 Apr 2003 12:03:10 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id A374E2A8A9; Fri, 4 Apr 2003 12:03:10 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Date: Fri, 04 Apr 2003 12:03:10 -0800 From: Peter Wemm Message-Id: <20030404200310.A374E2A8A9@canning.wemm.org> cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 20:03:11 -0000 Daniel Eischen wrote: > On Thu, 3 Apr 2003, Peter Wemm wrote: > > > Daniel Eischen wrote: > > > > > The patches are available: > > > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > > > FYI, since this is a new mailing list, the above changes > > > are meant to give libpthread M:N capability. > > > > > > I don't need testers; I have enough bugs that I know about > > > to fix. > > > > + __asm__("movl %%gs, %0" : "=r" (id)); > > + id >>= 3; > > + if (id - NLDT < 0) > > > > There is a problem here, NLDT is kernel private and changes depending on > > things like whether SMP is enabled or what the maximum number of cpus > > is. > > > > You're trying to find if its a local or global selector, right? > > What you really want is bit 2 which tells you which it is. > > > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > > #define SEL_LDT 4 /* local descriptor table */ > > OK, but if NLDT is kernel private, how do can I know > what LDTs I can use as local? Whoops. I misread NLDT as NGDT. Gah. We're doing some crufty stuff here. For starters, we're running userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a GDT slot for those. Most of the other stuff there is for the a.out "lcall 7,0" instruction and for BSDI's version of the lcall stuff. The i386_[gs]et_ldt() syscalls really should have a way of reporting what is available for use. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 14:09:56 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 24E3337B408 for ; Fri, 4 Apr 2003 14:09:56 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED11C43FAF for ; Fri, 4 Apr 2003 14:09:52 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003040422095100300p7svee>; Fri, 4 Apr 2003 22:09:52 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA37528; Fri, 4 Apr 2003 14:09:51 -0800 (PST) Date: Fri, 4 Apr 2003 14:09:49 -0800 (PST) From: Julian Elischer To: Peter Wemm In-Reply-To: <20030404200310.A374E2A8A9@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 22:09:56 -0000 On Fri, 4 Apr 2003, Peter Wemm wrote: > Daniel Eischen wrote: > > On Thu, 3 Apr 2003, Peter Wemm wrote: > > > > > Daniel Eischen wrote: > > > > > > > The patches are available: > > > > > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > > > > > FYI, since this is a new mailing list, the above changes > > > > are meant to give libpthread M:N capability. > > > > > > > > I don't need testers; I have enough bugs that I know about > > > > to fix. > > > > > > + __asm__("movl %%gs, %0" : "=r" (id)); > > > + id >>= 3; > > > + if (id - NLDT < 0) > > > > > > There is a problem here, NLDT is kernel private and changes depending on > > > things like whether SMP is enabled or what the maximum number of cpus > > > is. > > > > > > You're trying to find if its a local or global selector, right? > > > What you really want is bit 2 which tells you which it is. > > > > > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > > > #define SEL_LDT 4 /* local descriptor table */ > > > > OK, but if NLDT is kernel private, how do can I know > > what LDTs I can use as local? > > Whoops. I misread NLDT as NGDT. > > Gah. We're doing some crufty stuff here. For starters, we're running > userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a > GDT slot for those. Most of the other stuff there is for the a.out > "lcall 7,0" instruction and for BSDI's version of the lcall stuff. > > The i386_[gs]et_ldt() syscalls really should have a way of reporting what > is available for use. What we SHOULD be doing is setting an LDT entry to point to the mailbox (puts some constraints on the mailbox but..) of each upcall and setting %gs to teh appropriate entry before returning to userspace. (different schemes would be used for the other architectures.) > > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > _______________________________________________ > 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 Apr 4 14:26:10 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 3EDD937B404 for ; Fri, 4 Apr 2003 14:26:10 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A51D843FD7 for ; Fri, 4 Apr 2003 14:26:09 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0021.cvx22-bradley.dialup.earthlink.net ([209.179.198.21] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 191ZdL-0002En-00; Fri, 04 Apr 2003 14:26:03 -0800 Message-ID: <3E8E062F.2F69D32F@mindspring.com> Date: Fri, 04 Apr 2003 14:24:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030404200310.A374E2A8A9@canning.wemm.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fd97d2bdb6444bb00dc43e078f02f1c9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 22:26:10 -0000 Peter Wemm wrote: > > OK, but if NLDT is kernel private, how do can I know > > what LDTs I can use as local? > > Whoops. I misread NLDT as NGDT. > > Gah. We're doing some crufty stuff here. For starters, we're running > userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a > GDT slot for those. Most of the other stuff there is for the a.out > "lcall 7,0" instruction and for BSDI's version of the lcall stuff. > > The i386_[gs]et_ldt() syscalls really should have a way of reporting what > is available for use. I assume we are talking a process using per-process LDT's at the time of the calls? >From my reading of the i386_get_ldt()/i386_set_ldt() code, it looks like an i386_get_ldt() with an argument list of more than the number of per process LDT entries will return the current number of entries instead of the requested number of entries. This should be enough to get you the index of the "next" free entry, since the returned values aren't a sparse matrix. It also looks like i386_set_ldt() will reallocate the array larger, if you pass down an entry whose index is larger than the largest one, e.g.: if (!pldt || largest_ld >= pldt->ldt_len) { I would recommend, though, that only the new entries be set; in specific, the "start_sel" argument to i386_set_ldt() should be for only the new descriptor being allocated. So basically, you get with a huge number, it returns the actual number, and you set the one after that to allocate a new one. Anyway, maybe I'm not understanding why the discovery of a new descriptor available for allocation is a problem here? PS: I agree on the GDT, in principle, but in practice, is the number-of-entries limit that comes with that acceptable? That's where the TSS limit of 65536 comes from, right? -- Terry From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 14:39: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 1B3F437B401 for ; Fri, 4 Apr 2003 14:39:34 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFBF43FBF for ; Fri, 4 Apr 2003 14:39:33 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <20030404223931001002mtane>; Fri, 4 Apr 2003 22:39:32 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA37772; Fri, 4 Apr 2003 14:39:29 -0800 (PST) Date: Fri, 4 Apr 2003 14:39:28 -0800 (PST) From: Julian Elischer To: Peter Wemm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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, 04 Apr 2003 22:39:34 -0000 On Fri, 4 Apr 2003, Julian Elischer wrote: > > > On Fri, 4 Apr 2003, Peter Wemm wrote: > > > Daniel Eischen wrote: > > > On Thu, 3 Apr 2003, Peter Wemm wrote: > > > > > > > Daniel Eischen wrote: > > > > > > > > > The patches are available: > > > > > > > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > > > > > > > FYI, since this is a new mailing list, the above changes > > > > > are meant to give libpthread M:N capability. > > > > > > > > > > I don't need testers; I have enough bugs that I know about > > > > > to fix. > > > > > > > > + __asm__("movl %%gs, %0" : "=r" (id)); > > > > + id >>= 3; > > > > + if (id - NLDT < 0) > > > > > > > > There is a problem here, NLDT is kernel private and changes depending on > > > > things like whether SMP is enabled or what the maximum number of cpus > > > > is. > > > > > > > > You're trying to find if its a local or global selector, right? > > > > What you really want is bit 2 which tells you which it is. > > > > > > > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > > > > #define SEL_LDT 4 /* local descriptor table */ > > > > > > OK, but if NLDT is kernel private, how do can I know > > > what LDTs I can use as local? > > > > Whoops. I misread NLDT as NGDT. > > > > Gah. We're doing some crufty stuff here. For starters, we're running > > userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a > > GDT slot for those. Most of the other stuff there is for the a.out > > "lcall 7,0" instruction and for BSDI's version of the lcall stuff. > > > > The i386_[gs]et_ldt() syscalls really should have a way of reporting what > > is available for use. > > What we SHOULD be doing is setting an LDT entry to point to the > mailbox (puts some constraints on the mailbox but..) of each upcall > and setting %gs to teh appropriate entry before returning to userspace. by which I mean that the setting of the LDT would be done in the kse_create() call by the kernel. The userland would just have to offset off the g segment to find the current KSE/upcall mailbox which would have a pointer to the current thread.. > > (different schemes would be used for the other architectures.) > > > > > Cheers, > > -Peter > > -- > > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > > _______________________________________________ > > 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" > > > > _______________________________________________ > 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 Apr 4 21:29:40 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 6947F37B401 for ; Fri, 4 Apr 2003 21:29:40 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE5543F85 for ; Fri, 4 Apr 2003 21:29:39 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h355TYBg026107; Sat, 5 Apr 2003 00:29:34 -0500 (EST) Received: from localhost (eischen@localhost)h355TXdU026104; Sat, 5 Apr 2003 00:29:33 -0500 (EST) Date: Sat, 5 Apr 2003 00:29:33 -0500 (EST) From: Daniel Eischen 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: 1:N threading 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: Sat, 05 Apr 2003 05:29:40 -0000 On Fri, 4 Apr 2003, Julian Elischer wrote: > On Fri, 4 Apr 2003, Peter Wemm wrote: > > > Daniel Eischen wrote: > > > On Thu, 3 Apr 2003, Peter Wemm wrote: > > > > > > > Daniel Eischen wrote: > > > > > > > > > The patches are available: > > > > > > > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > > > > > > > FYI, since this is a new mailing list, the above changes > > > > > are meant to give libpthread M:N capability. > > > > > > > > > > I don't need testers; I have enough bugs that I know about > > > > > to fix. > > > > > > > > + __asm__("movl %%gs, %0" : "=r" (id)); > > > > + id >>= 3; > > > > + if (id - NLDT < 0) > > > > > > > > There is a problem here, NLDT is kernel private and changes depending on > > > > things like whether SMP is enabled or what the maximum number of cpus > > > > is. > > > > > > > > You're trying to find if its a local or global selector, right? > > > > What you really want is bit 2 which tells you which it is. > > > > > > > > #define ISLDT(s) ((s)&SEL_LDT) /* is it local or global */ > > > > #define SEL_LDT 4 /* local descriptor table */ > > > > > > OK, but if NLDT is kernel private, how do can I know > > > what LDTs I can use as local? > > > > Whoops. I misread NLDT as NGDT. > > > > Gah. We're doing some crufty stuff here. For starters, we're running > > userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a > > GDT slot for those. Most of the other stuff there is for the a.out > > "lcall 7,0" instruction and for BSDI's version of the lcall stuff. > > > > The i386_[gs]et_ldt() syscalls really should have a way of reporting what > > is available for use. > > What we SHOULD be doing is setting an LDT entry to point to the > mailbox (puts some constraints on the mailbox but..) of each upcall > and setting %gs to teh appropriate entry before returning to userspace. Well, we can do it just fine from userland and are doing it right now. The kernel doesn't really need to... But, if you want to do that, let's think about the interface and see if it makes sense for all architectures. If the kse_create() is going to do it, then we should probably pass in the size of the entry, or perhaps put the size in the kse mailbox with the mailbox address being the start address. That way we can put the kse mailbox in the (at the top) userland KSE structure and still be free to change the size. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 23:13:13 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 7537837B401 for ; Fri, 4 Apr 2003 23:13:13 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A20E43FBD for ; Fri, 4 Apr 2003 23:13:12 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h357DAmF054640 for ; Sat, 5 Apr 2003 11:13:10 +0400 (MSD) Date: Sat, 5 Apr 2003 11:13:10 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: freebsd-threads@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: 1:N threading 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: Sat, 05 Apr 2003 07:13:13 -0000 On Sat, 5 Apr 2003, Daniel Eischen wrote: > > > Gah. We're doing some crufty stuff here. For starters, we're running > > > userland on a LDT for %cs and %ds/es/ss/etc. We really should be using a > > > GDT slot for those. Most of the other stuff there is for the a.out > > > "lcall 7,0" instruction and for BSDI's version of the lcall stuff. If %cs/ss/ds/es would be moved to GDT then I think it would be helpfull to rearrange %cs and %ss so that %ss would be the next selector after %cs, i.e. %ss == %cs + 8. That order allows to use Intel's sysenter/sysexit instructions. I'm not sure about AMD's ones. > > > The i386_[gs]et_ldt() syscalls really should have a way of reporting what > > > is available for use. > > > > What we SHOULD be doing is setting an LDT entry to point to the > > mailbox (puts some constraints on the mailbox but..) of each upcall > > and setting %gs to teh appropriate entry before returning to userspace. > > Well, we can do it just fine from userland and are doing it > right now. The kernel doesn't really need to... But, if > you want to do that, let's think about the interface and > see if it makes sense for all architectures. > > If the kse_create() is going to do it, then we should probably > pass in the size of the entry, or perhaps put the size in the > kse mailbox with the mailbox address being the start address. > That way we can put the kse mailbox in the (at the top) userland > KSE structure and still be free to change the size. Julian's suggestion would allow to support more than 8192 KSEs per a proccess on x86 although such huge number of threads can be treated as a bad design. I think that %gs should contains LDT selector that permanent per CPU but not per KSE mailbox. KSE mailbox should be pointed by LDT descriptor that changed each time before returning to userspace. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-threads@FreeBSD.ORG Fri Apr 4 23:46:52 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 3DBC037B401 for ; Fri, 4 Apr 2003 23:46:52 -0800 (PST) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3107243FBF for ; Fri, 4 Apr 2003 23:46:51 -0800 (PST) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h357knmF055383; Sat, 5 Apr 2003 11:46:49 +0400 (MSD) Date: Sat, 5 Apr 2003 11:46:49 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3E8E062F.2F69D32F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading 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: Sat, 05 Apr 2003 07:46:52 -0000 On Fri, 4 Apr 2003, Terry Lambert wrote: > PS: I agree on the GDT, in principle, but in practice, is the > number-of-entries limit that comes with that acceptable? That's > where the TSS limit of 65536 comes from, right? No, there's no limit. All processes use the same GDT selectors that point to the same GDT descriptors that describe the same segments that start at 0 and end at 0xffffffff. And there's %cr3 that points to mapping that makes these segments different in each process. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 19:15:31 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 C4E1A37B401 for ; Sat, 5 Apr 2003 19:15:31 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F18E43F3F for ; Sat, 5 Apr 2003 19:15:31 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from xu (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h363FUUp026971 for ; Sat, 5 Apr 2003 19:15:30 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <001401c2fbeb$6d496c90$0701a8c0@xu> From: "DavidXu" To: Date: Sun, 6 Apr 2003 11:20:07 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: PS_BLOCKED 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, 06 Apr 2003 03:15:32 -0000 RGFuaWVsLA0KDQpJIHNhdyB5b3VyIGNvZGUgaW4gdGhyX2tlcm4uYyBhc3N1bWVzIHRoYXQgYSBi bG9ja2VkIHRocmVhZA0KaW4ga2VybmVsIHdpbGwgYWx3YXlzIGJlIHJldHVybmVkIGluIHNhbWUg dXBjYWxsKHlvdXIgdXNlcmxhbmQgDQprc2UpPyBIb3dldmVyLCBjdXJyZW50IGtlcm5lbCB3aWxs IHJldHVybmVkIHRoaXMgY29udGV4dCBpbiBvbmUNCm9mIHVwY2FsbCBpbiB0aGUgc2FtZSBrc2Vn cnAsIHNvIHRoZXJlIGlzIHJhY2UgaW4geW91ciBjb2RlLCANCkkgdGhpbmsgdGhpcyBtYXkgYmUg YSBrZXJuZWwgYnVnIGJ1dCBub3QgeW91cnMsIHRoaXMgZG9lcyBub3QNCnZlcnkgcmVzcGVjdHMg b3JpZ2luYWwgcGFwZXIuDQoNCg0KRGF2aWQgWHUNCg== From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 19:24:36 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 E1A4037B404 for ; Sat, 5 Apr 2003 19:24:36 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B83143F93 for ; Sat, 5 Apr 2003 19:24:36 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from xu (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h363OZUp029175 for ; Sat, 5 Apr 2003 19:24:35 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <002c01c2fbec$b23756e0$0701a8c0@xu> From: "DavidXu" To: Date: Sun, 6 Apr 2003 11:29:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: PS_BLOCKED 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, 06 Apr 2003 03:24:37 -0000 Daniel, I saw your code in thr_kern.c assumes that a blocked thread in kernel will always be returned in same upcall(your userland=20 kse)? However, current kernel will returned this context in one of upcall in the same ksegrp, so there is race in your code,=20 I think this may be a kernel bug but not yours, this does not very respects original paper. David Xu From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 22:40:55 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 5F92C37B401; Sat, 5 Apr 2003 22:40:55 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0EE543FAF; Sat, 5 Apr 2003 22:40:54 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h366epBg025736; Sun, 6 Apr 2003 01:40:51 -0500 (EST) Received: from localhost (eischen@localhost)h366epGx025729; Sun, 6 Apr 2003 01:40:51 -0500 (EST) Date: Sun, 6 Apr 2003 01:40:50 -0500 (EST) From: Daniel Eischen To: DavidXu In-Reply-To: <002c01c2fbec$b23756e0$0701a8c0@xu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 06 Apr 2003 06:40:55 -0000 On Sun, 6 Apr 2003, DavidXu wrote: > Daniel, > > I saw your code in thr_kern.c assumes that a blocked thread > in kernel will always be returned in same upcall(your userland > kse)? However, current kernel will returned this context in one > of upcall in the same ksegrp, so there is race in your code, > I think this may be a kernel bug but not yours, this does not > very respects original paper. Hey, glad to see you got through to an @freebsd.org list from home (I presume)! Actually, I got rid of PS_BLOCKED earlier today. I think I deal with blocked threads OK now and I don't think I assume (any longer) that they belong to any particular KSE. I've made some decent progress and can run the mutex test sucessfully, and can run most of the ACE tests also. Some of the ACE tests fail, but some also fail with libc_r (I don't think it's the threads library). I'm running them with libc_r now and will compare against libkse. I've still got one bug I am trying to hunt down with signals -- the sigwait test fails. Process (kill) signals don't seem to wakeup threads in sigwait(). I'm not sure if it is a kernel bug or not, but I suspect it's something I'm doing. One question. What happens when kse_release(tsp) is called when k_mbx.km_curthread == NULL? Does it just return after the timeout, or is there a new upcall? And if kse_A->k_mbx.km_curthread == NULL and it is in a kse_release(tsp), can another kse interrupt it (before the timeout) with kse_wakeup()? -- Dan Eischen Let's Go Orange! From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 23:19:01 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 58D5137B405; Sat, 5 Apr 2003 23:19:01 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0639843FBD; Sat, 5 Apr 2003 23:19:01 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h367IxUp091513; Sat, 5 Apr 2003 23:19:00 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <000d01c2fc0d$6d404c60$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: Date: Sun, 6 Apr 2003 15:23:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 06 Apr 2003 07:19:01 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhbmllbCBFaXNjaGVuIiA8 ZWlzY2hlbkBwY25ldDEucGNuZXQuY29tPg0KVG86ICJEYXZpZFh1IiA8ZGF2aWR4dUBmcmVlYnNk Lm9yZz4NCkNjOiA8ZnJlZWJzZC10aHJlYWRzQGZyZWVic2Qub3JnPg0KU2VudDogU3VuZGF5LCBB cHJpbCAwNiwgMjAwMyAyOjQwIFBNDQpTdWJqZWN0OiBSZTogUFNfQkxPQ0tFRA0KDQoNCj4gT24g U3VuLCA2IEFwciAyMDAzLCBEYXZpZFh1IHdyb3RlOg0KPiANCj4gPiBEYW5pZWwsDQo+ID4gDQo+ ID4gSSBzYXcgeW91ciBjb2RlIGluIHRocl9rZXJuLmMgYXNzdW1lcyB0aGF0IGEgYmxvY2tlZCB0 aHJlYWQNCj4gPiBpbiBrZXJuZWwgd2lsbCBhbHdheXMgYmUgcmV0dXJuZWQgaW4gc2FtZSB1cGNh bGwoeW91ciB1c2VybGFuZCANCj4gPiBrc2UpPyBIb3dldmVyLCBjdXJyZW50IGtlcm5lbCB3aWxs IHJldHVybmVkIHRoaXMgY29udGV4dCBpbiBvbmUNCj4gPiBvZiB1cGNhbGwgaW4gdGhlIHNhbWUg a3NlZ3JwLCBzbyB0aGVyZSBpcyByYWNlIGluIHlvdXIgY29kZSwgDQo+ID4gSSB0aGluayB0aGlz IG1heSBiZSBhIGtlcm5lbCBidWcgYnV0IG5vdCB5b3VycywgdGhpcyBkb2VzIG5vdA0KPiA+IHZl cnkgcmVzcGVjdHMgb3JpZ2luYWwgcGFwZXIuDQo+IA0KPiBIZXksIGdsYWQgdG8gc2VlIHlvdSBn b3QgdGhyb3VnaCB0byBhbiBAZnJlZWJzZC5vcmcgbGlzdA0KPiBmcm9tIGhvbWUgKEkgcHJlc3Vt ZSkhDQo+IA0KPiBBY3R1YWxseSwgSSBnb3QgcmlkIG9mIFBTX0JMT0NLRUQgZWFybGllciB0b2Rh eS4gIEkgdGhpbmsNCj4gSSBkZWFsIHdpdGggYmxvY2tlZCB0aHJlYWRzIE9LIG5vdyBhbmQgSSBk b24ndCB0aGluayBJDQo+IGFzc3VtZSAoYW55IGxvbmdlcikgdGhhdCB0aGV5IGJlbG9uZyB0byBh bnkgcGFydGljdWxhcg0KPiBLU0UuDQo+IA0KPiBJJ3ZlIG1hZGUgc29tZSBkZWNlbnQgcHJvZ3Jl c3MgYW5kIGNhbiBydW4gdGhlIG11dGV4IHRlc3QNCj4gc3VjZXNzZnVsbHksIGFuZCBjYW4gcnVu IG1vc3Qgb2YgdGhlIEFDRSB0ZXN0cyBhbHNvLiAgU29tZQ0KPiBvZiB0aGUgQUNFIHRlc3RzIGZh aWwsIGJ1dCBzb21lIGFsc28gZmFpbCB3aXRoIGxpYmNfcg0KPiAoSSBkb24ndCB0aGluayBpdCdz IHRoZSB0aHJlYWRzIGxpYnJhcnkpLiAgSSdtIHJ1bm5pbmcNCj4gdGhlbSB3aXRoIGxpYmNfciBu b3cgYW5kIHdpbGwgY29tcGFyZSBhZ2FpbnN0IGxpYmtzZS4NCj4gDQpDb25ncmF0dWxhdGlvbiEg SSBrbm93IEFDRSBpcyBhIGJpZyBtb25zdGVyLCBpdCBpcyBhIHZlcnkgcHJhY3RpY2FsDQp0ZXN0 IHN1aXQuDQoNCj4gSSd2ZSBzdGlsbCBnb3Qgb25lIGJ1ZyBJIGFtIHRyeWluZyB0byBodW50IGRv d24gd2l0aA0KPiBzaWduYWxzIC0tIHRoZSBzaWd3YWl0IHRlc3QgZmFpbHMuICBQcm9jZXNzIChr aWxsKSBzaWduYWxzDQo+IGRvbid0IHNlZW0gdG8gd2FrZXVwIHRocmVhZHMgaW4gc2lnd2FpdCgp LiAgSSdtIG5vdCBzdXJlDQo+IGlmIGl0IGlzIGEga2VybmVsIGJ1ZyBvciBub3QsIGJ1dCBJIHN1 c3BlY3QgaXQncw0KPiBzb21ldGhpbmcgSSdtIGRvaW5nLg0KPiANCg0KSSBkb24ndCBrbm93IGlm IEplZmYncyBzaWduYWwgY2hhbmdlIGluIGtlcm5lbCBhZmZlY3RzIHlvdXIgY29kZSwNCmJ1dCBz aWduYWxzIGxvc3QgcHJvYmxlbSBpcyBzdGlsbCBub3QgZml4ZWQsIGEgdGhyZWFkIGV4cG9ydHMg aXRzDQpjb250ZXh0IGFuZCBleGl0cyB3b3VsZCBsb3N0IHNpZ25hbHMgZGlzcGF0Y2hlZCB0byBp dCwgZXZlbiB0aGUNCnNpZ25hbHMgaXMgbm90IGZvciB0aGUgdGhyZWFkLCBidXQgZm9yIHByb2Nl c3MuDQoNCj4gT25lIHF1ZXN0aW9uLiAgV2hhdCBoYXBwZW5zIHdoZW4ga3NlX3JlbGVhc2UodHNw KSBpcw0KPiBjYWxsZWQgd2hlbiBrX21ieC5rbV9jdXJ0aHJlYWQgPT0gTlVMTD8gIERvZXMgaXQN Cj4ganVzdCByZXR1cm4gYWZ0ZXIgdGhlIHRpbWVvdXQsIG9yIGlzIHRoZXJlIGEgbmV3DQo+IHVw Y2FsbD8NCg0KQSBuZXcgdXBjYWxsIHdpbGwgYmUgc2NoZWR1bGVkLCBkb2VzIG5vdCByZXR1cm4u DQoNCj4gIEFuZCBpZiBrc2VfQS0+a19tYngua21fY3VydGhyZWFkID09IE5VTEwNCj4gYW5kIGl0 IGlzIGluIGEga3NlX3JlbGVhc2UodHNwKSwgY2FuIGFub3RoZXIga3NlDQo+IGludGVycnVwdCBp dCAoYmVmb3JlIHRoZSB0aW1lb3V0KSB3aXRoIGtzZV93YWtldXAoKT8NCj4gDQpZZXMsIHlvdSBj YW4gdXNlIGtzZV93YWtldXAgdG8gaW50ZXJydXB0IGl0LCBwYXNzIHRoZQ0Ka3NlIG1haWxib3gg YWRkcmVzcyB0byB0aGUgc3lzY2FsbC4NCg0KPiAtLSANCj4gRGFuIEVpc2NoZW4NCj4gDQo+IA0K PiBMZXQncyBHbyBPcmFuZ2UhDQoNCldvdWxkIHRoZXJlIGJlIGEgbmV3IHBhdGNoIGFnYWluc3Qg Y29kZSBpbiB0aGUgc3JjIHRyZWUgDQpJIGNhbiBkb3dubG9hZCA/DQoNCkRhdmlkIFh1DQoNCg0K From owner-freebsd-threads@FreeBSD.ORG Sat Apr 5 23:47:38 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 895A437B401; Sat, 5 Apr 2003 23:47:38 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id D09D343FAF; Sat, 5 Apr 2003 23:47:37 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003040607473600300p70c0e>; Sun, 6 Apr 2003 07:47:36 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA49892; Sat, 5 Apr 2003 23:47:35 -0800 (PST) Date: Sat, 5 Apr 2003 23:47:34 -0800 (PST) From: Julian Elischer To: DavidXu In-Reply-To: <001401c2fbeb$6d496c90$0701a8c0@xu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 06 Apr 2003 07:47:38 -0000 On Sun, 6 Apr 2003, DavidXu wrote: > Daniel, > > I saw your code in thr_kern.c assumes that a blocked thread > in kernel will always be returned in same upcall(your userland > kse)? However, current kernel will returned this context in one > of upcall in the same ksegrp, so there is race in your code, > I think this may be a kernel bug but not yours, this does not > very respects original paper. it has always been said that a blocked thread will have its context returned on any KSE(upcall) in that group. (the next one) > > > David Xu >