From owner-freebsd-threads@FreeBSD.ORG Sun May 4 06:30: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 78E0737B401 for ; Sun, 4 May 2003 06:30:45 -0700 (PDT) Received: from mail.highway.ne.jp (mail.highway.ne.jp [210.166.100.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B9843FAF for ; Sun, 4 May 2003 06:30:44 -0700 (PDT) (envelope-from kaakun@highway.ne.jp) Received: from face.violasystems.net (ppp0120.vc-tyo.hdd.co.jp [218.228.39.20]) by mail.highway.ne.jp (8.9.3p2/3.7W03043010) with SMTP id WAA16388 for ; Sun, 4 May 2003 22:30:39 +0900 (JST) Date: Sun, 4 May 2003 22:30:22 +0900 From: Kazuaki Oda To: threads@freebsd.org Message-Id: <20030504223022.5335f30f.kaakun@highway.ne.jp> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sun__4_May_2003_22:30:22_+0900_0822d600" Subject: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 04 May 2003 13:30:45 -0000 This is a multi-part message in MIME format. --Multipart_Sun__4_May_2003_22:30:22_+0900_0822d600 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, After applying the attached patch, I've been able to run Java2D demo under jdk-1.4.1p3_3 with libpthread (libkse). This patch is for problem with suspending and resuming thread. Please review. -- Kazuaki Oda (kaakun@highway.ne.jp) --Multipart_Sun__4_May_2003_22:30:22_+0900_0822d600 Content-Type: application/octet-stream; name="libpthread_jdk.diff" Content-Disposition: attachment; filename="libpthread_jdk.diff" Content-Transfer-Encoding: base64 ZGlmZiAtcnUgbGlicHRocmVhZC5vcmlnL3RocmVhZC90aHJfY3JlYXRlLmMgbGlicHRocmVhZC90 aHJlYWQvdGhyX2NyZWF0ZS5jCi0tLSBsaWJwdGhyZWFkLm9yaWcvdGhyZWFkL3Rocl9jcmVhdGUu YwlUaHUgTWF5ICAxIDAyOjA4OjEyIDIwMDMKKysrIGxpYnB0aHJlYWQvdGhyZWFkL3Rocl9jcmVh dGUuYwlTdW4gTWF5ICA0IDAwOjQ0OjI4IDIwMDMKQEAgLTI1OSw5ICsyNTksMTAgQEAKIAkJCW5l d190aHJlYWQtPmZsYWdzID0gMDsKIAkJCW5ld190aHJlYWQtPmNvbnRpbnVhdGlvbiA9IE5VTEw7 CiAKLQkJCWlmIChuZXdfdGhyZWFkLT5hdHRyLnN1c3BlbmQgPT0gVEhSX0NSRUFURV9TVVNQRU5E RUQpCisJCQlpZiAobmV3X3RocmVhZC0+YXR0ci5zdXNwZW5kID09IFRIUl9DUkVBVEVfU1VTUEVO REVEKSB7CiAJCQkJbmV3X3RocmVhZC0+c3RhdGUgPSBQU19TVVNQRU5ERUQ7Ci0JCQllbHNlCisJ CQkJbmV3X3RocmVhZC0+ZmxhZ3MgPSBUSFJfRkxBR1NfU1VTUEVOREVEOworCQkJfSBlbHNlCiAJ CQkJbmV3X3RocmVhZC0+c3RhdGUgPSBQU19SVU5OSU5HOwogCiAJCQkvKgpkaWZmIC1ydSBsaWJw dGhyZWFkLm9yaWcvdGhyZWFkL3Rocl9yZXN1bWVfbnAuYyBsaWJwdGhyZWFkL3RocmVhZC90aHJf cmVzdW1lX25wLmMKLS0tIGxpYnB0aHJlYWQub3JpZy90aHJlYWQvdGhyX3Jlc3VtZV9ucC5jCUZy aSBBcHIgMTggMTY6MDk6NDMgMjAwMworKysgbGlicHRocmVhZC90aHJlYWQvdGhyX3Jlc3VtZV9u cC5jCVN1biBNYXkgIDQgMjI6MDM6MzEgMjAwMwpAQCAtNTcsNyArNTcsNyBAQAogCiAJCQlpZiAo KGN1cnRocmVhZC0+c3RhdGUgIT0gUFNfREVBRCkgJiYKIAkJCSAgICAoY3VydGhyZWFkLT5zdGF0 ZSAhPSBQU19ERUFETE9DSykgJiYKLQkJCSAgICAoKGN1cnRocmVhZC0+ZmxhZ3MgJiBUSFJfRkxB R1NfRVhJVElORykgIT0gMCkpCisJCQkgICAgKChjdXJ0aHJlYWQtPmZsYWdzICYgVEhSX0ZMQUdT X0VYSVRJTkcpID09IDApKQogCQkJCXJlc3VtZV9jb21tb24odGhyZWFkKTsKIAogCQkJLyogVW5s b2NrIHRoZSB0aHJlYWRzIHNjaGVkdWxpbmcgcXVldWU6ICovCkBAIC0xMDcsNiArMTA3LDcgQEAK IAkgKiBub3cgcnVubmFibGUgYnV0IG5vdCBpbiBhbnkgc2NoZWR1bGluZyBxdWV1ZS4gIFNldCB0 aGUKIAkgKiBzdGF0ZSB0byBydW5uaW5nIGFuZCBpbnNlcnQgaXQgaW50byB0aGUgcnVuIHF1ZXVl LgogCSAqLwotCWlmICh0aHJlYWQtPnN0YXRlID09IFBTX1NVU1BFTkRFRCkKKwlpZiAodGhyZWFk LT5zdGF0ZSA9PSBQU19TVVNQRU5ERUQgJiYKKwkgICAgKHRocmVhZC0+c2ZsYWdzICYgVEhSX0ZM QUdTX0lOX1NZTkNRKSA9PSAwKQogCQlfdGhyX3NldHJ1bm5hYmxlX3VubG9ja2VkKHRocmVhZCk7 CiB9Cg== --Multipart_Sun__4_May_2003_22:30:22_+0900_0822d600-- From owner-freebsd-threads@FreeBSD.ORG Sun May 4 09:19:03 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 2D4F537B401 for ; Sun, 4 May 2003 09:19:03 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C19C43FA3 for ; Sun, 4 May 2003 09:19:00 -0700 (PDT) (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 h44GIxBg012363; Sun, 4 May 2003 12:18:59 -0400 (EDT) Received: from localhost (eischen@localhost)h44GIwmH012360; Sun, 4 May 2003 12:18:58 -0400 (EDT) Date: Sun, 4 May 2003 12:18:58 -0400 (EDT) From: Daniel Eischen To: Kazuaki Oda In-Reply-To: <20030504223022.5335f30f.kaakun@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 04 May 2003 16:19:03 -0000 On Sun, 4 May 2003, Kazuaki Oda wrote: > Hi, > > After applying the attached patch, I've been able to run Java2D demo > under jdk-1.4.1p3_3 with libpthread (libkse). > > This patch is for problem with suspending and resuming thread. I just commited this, but modified a bit. Please check it and see that it works as expected. Thanks! -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun May 4 10:33:51 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 B636437B401 for ; Sun, 4 May 2003 10:33:51 -0700 (PDT) Received: from mail.highway.ne.jp (mail.highway.ne.jp [210.166.100.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E2843FB1 for ; Sun, 4 May 2003 10:33:50 -0700 (PDT) (envelope-from kaakun@highway.ne.jp) Received: from face.violasystems.net (ppp0615.vc-tyo.hdd.co.jp [219.100.26.15]) by mail.highway.ne.jp (8.9.3p2/3.7W03043010) with SMTP id CAA09669; Mon, 5 May 2003 02:33:39 +0900 (JST) Date: Mon, 5 May 2003 02:33:24 +0900 From: Kazuaki Oda To: Daniel Eischen Message-Id: <20030505023324.09dd90e0.kaakun@highway.ne.jp> In-Reply-To: References: <20030504223022.5335f30f.kaakun@highway.ne.jp> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 04 May 2003 17:33:52 -0000 On Sun, 4 May 2003 12:18:58 -0400 (EDT) Daniel Eischen wrote: > On Sun, 4 May 2003, Kazuaki Oda wrote: > > Hi, > > > > After applying the attached patch, I've been able to run Java2D demo > > under jdk-1.4.1p3_3 with libpthread (libkse). > > > > This patch is for problem with suspending and resuming thread. > > I just commited this, but modified a bit. Please check it and > see that it works as expected. > > Thanks! > > -- > Dan Eischen > > Thank you for commiting. I just tested this, and it works fine except for sometimes hanging up. When it occurs, the only thing I can is send SIGKILL to the java process. I think this is because of rtld problem, right? -- Kazuaki Oda (kaakun@highway.ne.jp) From owner-freebsd-threads@FreeBSD.ORG Sun May 4 11:00: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 9095937B401 for ; Sun, 4 May 2003 11:00:19 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 958DB43F3F for ; Sun, 4 May 2003 11:00:18 -0700 (PDT) (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 h44I0HBg024225; Sun, 4 May 2003 14:00:17 -0400 (EDT) Received: from localhost (eischen@localhost)h44I0HQ7024220; Sun, 4 May 2003 14:00:17 -0400 (EDT) Date: Sun, 4 May 2003 14:00:17 -0400 (EDT) From: Daniel Eischen To: Kazuaki Oda In-Reply-To: <20030505023324.09dd90e0.kaakun@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 04 May 2003 18:00:19 -0000 On Mon, 5 May 2003, Kazuaki Oda wrote: > On Sun, 4 May 2003 12:18:58 -0400 (EDT) > Daniel Eischen wrote: > > > On Sun, 4 May 2003, Kazuaki Oda wrote: > > > Hi, > > > > > > After applying the attached patch, I've been able to run Java2D demo > > > under jdk-1.4.1p3_3 with libpthread (libkse). > > > > > > This patch is for problem with suspending and resuming thread. > > > > I just commited this, but modified a bit. Please check it and > > see that it works as expected. > > > > Thanks! > > > > -- > > Dan Eischen > > > > > > Thank you for commiting. I just tested this, and it works fine except > for sometimes hanging up. > When it occurs, the only thing I can is send SIGKILL to the java process. > I think this is because of rtld problem, right? Yes, I think so. You can try the patch I posted in: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179964+0+archive/2003/freebsd-threads/20030504.freebsd-threads to see if that fixes the problem with rtld-elf. I don't want to commit it because it would break round-robin scheduling. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun May 4 17:19:48 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 7CEDA37B401; Sun, 4 May 2003 17:19:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED2343F75; Sun, 4 May 2003 17:19:46 -0700 (PDT) (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 h450JhUp063586; Sun, 4 May 2003 17:19:44 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001701c3129c$78bdab00$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" , "Kazuaki Oda" References: Date: Mon, 5 May 2003 08:22:52 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 00:19:48 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "Kazuaki Oda" Cc: Sent: Monday, May 05, 2003 2:00 AM Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) > Yes, I think so. You can try the patch I posted in: > =20 > = http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D179964+0+archive/2003/free= bsd-threads/20030504.freebsd-threads >=20 > to see if that fixes the problem with rtld-elf. I don't want to = commit it > because it would break round-robin scheduling. >=20 Is there anyone working on rtld-elf problem? > --=20 > Dan Eischen >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-threads@FreeBSD.ORG Sun May 4 21:12:43 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 D723F37B401 for ; Sun, 4 May 2003 21:12:43 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3334F43FB1 for ; Sun, 4 May 2003 21:12:43 -0700 (PDT) (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 h454CgBg017061; Mon, 5 May 2003 00:12:42 -0400 (EDT) Received: from localhost (eischen@localhost)h454CerA017058; Mon, 5 May 2003 00:12:41 -0400 (EDT) Date: Mon, 5 May 2003 00:12:39 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <001701c3129c$78bdab00$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 05 May 2003 04:12:44 -0000 On Mon, 5 May 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "Kazuaki Oda" > Cc: > Sent: Monday, May 05, 2003 2:00 AM > Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) > > > Yes, I think so. You can try the patch I posted in: > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179964+0+archive/2003/freebsd-threads/20030504.freebsd-threads > > > > to see if that fixes the problem with rtld-elf. I don't want to commit it > > because it would break round-robin scheduling. > > > Is there anyone working on rtld-elf problem? Alexander Kabaev said he was. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun May 4 23: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 2CD1337B401 for ; Sun, 4 May 2003 23:49:41 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 980A343F75 for ; Sun, 4 May 2003 23:49:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0107.cvx22-bradley.dialup.earthlink.net ([209.179.198.107] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CZmq-0004ih-00; Sun, 04 May 2003 23:49:21 -0700 Message-ID: <3EB60924.A595C548@mindspring.com> Date: Sun, 04 May 2003 23:48:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Xu References: <001701c3129c$78bdab00$0701a8c0@tiger> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a413142e30dc8c32d103490e14f316b43193caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 05 May 2003 06:49:41 -0000 David Xu wrote: > From: "Daniel Eischen" > > Yes, I think so. You can try the patch I posted in: > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179964+0+archive/2003/freebsd-threads/20030504.freebsd-threads > > > > to see if that fixes the problem with rtld-elf. I don't want to commit it > > because it would break round-robin scheduling. > > Is there anyone working on rtld-elf problem? Dan is; Alexander Kabaev is. Personally, I don't think this is justifiable, and that the problem is actually a coding error in the threaded program, with failure to comply with the POSIX and Single UNIX Specification when writing your threaded program. The pthreads documentation seems to back me up (Chapter 12 of "Go Solo 2", as well as Corrigenda). You can't put training wheels on everything for everyone; the fix Dan posted (I suggested the fix, based on my suspicion that it was a programming error in the threaded program) is training wheels: it makes the illegal-according-to-POSIX assumption true, that the same thread that was running at the time of an involuntary context switch will get the CPU back, instead of a higher priority threads. It corrects the problem; ipso facto, the problem is that someone is making an illegal-according-to-POSIX assumption. The correct thing to do is to modify the JDK or any other threaded program to *NOT* make that assumption, or to acquire a scheduler mutex, if it wants to make the assumption, so that there's a serialization barrier. Again: the rtld-elf is an effect of a bad assumption on the part of the threaded program, not a real bug in rtld-elf. -- Terry From owner-freebsd-threads@FreeBSD.ORG Mon May 5 04:12:58 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 73CDB37B401 for ; Mon, 5 May 2003 04:12:58 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B904943F85 for ; Mon, 5 May 2003 04:12:57 -0700 (PDT) (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 h45BCuBg015760; Mon, 5 May 2003 07:12:56 -0400 (EDT) Received: from localhost (eischen@localhost)h45BCmoV015747; Mon, 5 May 2003 07:12:48 -0400 (EDT) Date: Mon, 5 May 2003 07:12:48 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EB60924.A595C548@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 05 May 2003 11:12:58 -0000 On Sun, 4 May 2003, Terry Lambert wrote: > David Xu wrote: > > From: "Daniel Eischen" > > > Yes, I think so. You can try the patch I posted in: > > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179964+0+archive/2003/freebsd-threads/20030504.freebsd-threads > > > > > > to see if that fixes the problem with rtld-elf. I don't want to commit it > > > because it would break round-robin scheduling. > > > > Is there anyone working on rtld-elf problem? > > Dan is; Alexander Kabaev is. > > Personally, I don't think this is justifiable, and that the > problem is actually a coding error in the threaded program, > with failure to comply with the POSIX and Single UNIX > Specification when writing your threaded program. The pthreads > documentation seems to back me up (Chapter 12 of "Go Solo 2", > as well as Corrigenda). It *is* an rtld-elf problem. I've protected dlfoo() all with the same mutex and it still hangs. rtld-elf uses spinlocks in areas that aren't called by dlfoo(). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon May 5 16:54: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 6DA8F37B401 for ; Mon, 5 May 2003 16:54:05 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id C653843F75 for ; Mon, 5 May 2003 16:54:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc01) with ESMTP id <2003050523540300100cskk6e>; Mon, 5 May 2003 23:54:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA30234 for ; Mon, 5 May 2003 16:54:03 -0700 (PDT) Date: Mon, 5 May 2003 16:54:01 -0700 (PDT) From: Julian Elischer To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: kern_threads.c.. upcall question.. 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, 05 May 2003 23:54:05 -0000 In kern_threads.c, in function thread_export_context() it first does a copyin() of the context storage area. I think this is un-needed (and a complete waste of cycles) but I am not sure if there is some strange condition regarding floating point registers or something that may want this.. Dan, Jon, David? do any of you have a good reason why I shouldn't remove the copyin().?? From owner-freebsd-threads@FreeBSD.ORG Mon May 5 16:58:49 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 8F4C637B401 for ; Mon, 5 May 2003 16:58:49 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D95BB43F93 for ; Mon, 5 May 2003 16:58:48 -0700 (PDT) (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 h45NwiBg019981; Mon, 5 May 2003 19:58:44 -0400 (EDT) Received: from localhost (eischen@localhost)h45NwiH1019978; Mon, 5 May 2003 19:58:44 -0400 (EDT) Date: Mon, 5 May 2003 19:58:44 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: kern_threads.c.. upcall question.. 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, 05 May 2003 23:58:49 -0000 On Mon, 5 May 2003, Julian Elischer wrote: > > In kern_threads.c, in function thread_export_context() > it first does a copyin() of the > context storage area. I think this is un-needed (and a complete waste of > cycles) but I am not sure if there is some strange condition > regarding floating point registers or something that may want this.. > > Dan, Jon, David? > do any of you have a good reason why I shouldn't remove the copyin().?? Yeah, the threads library keeps the thread's active signal mask in the context area. The stack and flags may also be used in the context. You should be able to safely copy out the mcontext without a copyin(). Is that what you're currently doing? Or is the entire context (ucontext) being exported? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon May 5 17:39: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 DB74637B401 for ; Mon, 5 May 2003 17:39:57 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AE7043FB1 for ; Mon, 5 May 2003 17:39:57 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc52) with ESMTP id <20030506003956052006p7hbe>; Tue, 6 May 2003 00:39:57 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA30558; Mon, 5 May 2003 17:39:56 -0700 (PDT) Date: Mon, 5 May 2003 17:39:55 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 00:39:58 -0000 On Mon, 5 May 2003, Daniel Eischen wrote: > On Mon, 5 May 2003, Julian Elischer wrote: > > > > > In kern_threads.c, in function thread_export_context() > > it first does a copyin() of the > > context storage area. I think this is un-needed (and a complete waste of > > cycles) but I am not sure if there is some strange condition > > regarding floating point registers or something that may want this.. > > > > Dan, Jon, David? > > do any of you have a good reason why I shouldn't remove the copyin().?? > > Yeah, the threads library keeps the thread's active signal > mask in the context area. The stack and flags may also > be used in the context. > > You should be able to safely copy out the mcontext without > a copyin(). Is that what you're currently doing? Or is > the entire context (ucontext) being exported? it does: *) copyin the ucontext_t *) load context into it using thread_getcontext() which uses get_mcontext() and adds the kernel thread sigmask (this must have been added by jeff in some way) (note it doesn't OR, just writes) *) copyout of the ucontext_t The ucontext is: sigset_t uc_sigmask; <-- gets over-written (!) mcontext_t uc_mcontext; <-- gets over-written struct __ucontext *uc_link; <-- one in userland MAY be valuable stack_t uc_stack; <-- probably worth saving.. int uc_flags; <-- probably worth saving int __spare__[4]; It seems to me that just copying out the sigset_t and mcontext_t may be all that is needed. (and I'm not so sure about the sigset_t at that.. > > -- > Dan Eischen > > From owner-freebsd-threads@FreeBSD.ORG Mon May 5 17:49: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 5571537B401 for ; Mon, 5 May 2003 17:49:57 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8997343FA3 for ; Mon, 5 May 2003 17:49:56 -0700 (PDT) (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 h460noBg027811; Mon, 5 May 2003 20:49:50 -0400 (EDT) Received: from localhost (eischen@localhost)h460nolq027808; Mon, 5 May 2003 20:49:50 -0400 (EDT) Date: Mon, 5 May 2003 20:49:50 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 00:49:57 -0000 On Mon, 5 May 2003, Julian Elischer wrote: > On Mon, 5 May 2003, Daniel Eischen wrote: > > > On Mon, 5 May 2003, Julian Elischer wrote: > > > > > > > > In kern_threads.c, in function thread_export_context() > > > it first does a copyin() of the > > > context storage area. I think this is un-needed (and a complete waste of > > > cycles) but I am not sure if there is some strange condition > > > regarding floating point registers or something that may want this.. > > > > > > Dan, Jon, David? > > > do any of you have a good reason why I shouldn't remove the copyin().?? > > > > Yeah, the threads library keeps the thread's active signal > > mask in the context area. The stack and flags may also > > be used in the context. > > > > You should be able to safely copy out the mcontext without > > a copyin(). Is that what you're currently doing? Or is > > the entire context (ucontext) being exported? > > it does: > > *) copyin the ucontext_t > > *) load context into it using thread_getcontext() which uses > get_mcontext() and adds the kernel thread sigmask (this must have > been added by jeff in some way) (note it doesn't OR, just writes) Eek. That could cause problems for libpthread. We don't want the kernel thread signal mask being copied to the exported context. > *) copyout of the ucontext_t > > The ucontext is: > > sigset_t uc_sigmask; <-- gets over-written (!) > mcontext_t uc_mcontext; <-- gets over-written > struct __ucontext *uc_link; <-- one in userland MAY be > valuable > stack_t uc_stack; <-- probably worth saving.. > int uc_flags; <-- probably worth saving > int __spare__[4]; > > > > > It seems to me that just copying out the sigset_t and mcontext_t > may be all that is needed. (and I'm not so sure about the sigset_t > at that.. Yes, please don't copyout the sigset. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon May 5 19:14: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 DF94937B401; Mon, 5 May 2003 19:14:18 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B6F43F85; Mon, 5 May 2003 19:14:18 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h462EFUp031675; Mon, 5 May 2003 19:14:16 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <019f01c31375$7dcec4b0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" , "Julian Elischer" References: Date: Tue, 6 May 2003 10:16:20 +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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 02:14:19 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "Julian Elischer" Cc: Sent: Tuesday, May 06, 2003 8:49 AM Subject: Re: kern_threads.c.. upcall question.. > On Mon, 5 May 2003, Julian Elischer wrote: > > On Mon, 5 May 2003, Daniel Eischen wrote: > >=20 > > > On Mon, 5 May 2003, Julian Elischer wrote: > > >=20 > > > >=20 > > > > In kern_threads.c, in function thread_export_context() > > > > it first does a copyin() of the > > > > context storage area. I think this is un-needed (and a complete = waste of > > > > cycles) but I am not sure if there is some strange condition > > > > regarding floating point registers or something that may want = this.. > > > >=20 > > > > Dan, Jon, David? > > > > do any of you have a good reason why I shouldn't remove the = copyin().?? > > >=20 > > > Yeah, the threads library keeps the thread's active signal > > > mask in the context area. The stack and flags may also > > > be used in the context. > > >=20 > > > You should be able to safely copy out the mcontext without > > > a copyin(). Is that what you're currently doing? Or is > > > the entire context (ucontext) being exported? > >=20 > > it does: > >=20 > > *) copyin the ucontext_t > >=20 > > *) load context into it using thread_getcontext() which uses > > get_mcontext() and adds the kernel thread sigmask (this must have > > been added by jeff in some way) (note it doesn't OR, just writes) >=20 > Eek. That could cause problems for libpthread. We > don't want the kernel thread signal mask being copied > to the exported context. >=20 > > *) copyout of the ucontext_t > >=20 > > The ucontext is: > >=20 > > sigset_t uc_sigmask; <-- gets over-written (!) > > mcontext_t uc_mcontext; <-- gets over-written > > struct __ucontext *uc_link; <-- one in userland MAY be > > valuable > > stack_t uc_stack; <-- probably worth saving.. > > int uc_flags; <-- probably worth saving > > int __spare__[4]; > >=20 > >=20 > >=20 > >=20 > > It seems to me that just copying out the sigset_t and mcontext_t > > may be all that is needed. (and I'm not so sure about the sigset_t > > at that.. >=20 > Yes, please don't copyout the sigset. >=20 > --=20 > Dan Eischen Yes, I think only copying out mcontext is enough, we needn't copying in. David Xu From owner-freebsd-threads@FreeBSD.ORG Mon May 5 20:02: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 5326D37B401 for ; Mon, 5 May 2003 20:02:31 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E3D43F3F for ; Mon, 5 May 2003 20:02:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Csid-0007Z2-00; Mon, 05 May 2003 20:02:16 -0700 Message-ID: <3EB7256E.844A5958@mindspring.com> Date: Mon, 05 May 2003 20:01:02 -0700 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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41e42fb83694a87916a90e6181eb5b7c8a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: David Xu cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 06 May 2003 03:02:31 -0000 Daniel Eischen wrote: > > Personally, I don't think this is justifiable, and that the > > problem is actually a coding error in the threaded program, > > with failure to comply with the POSIX and Single UNIX > > Specification when writing your threaded program. The pthreads > > documentation seems to back me up (Chapter 12 of "Go Solo 2", > > as well as Corrigenda). > > It *is* an rtld-elf problem. I've protected dlfoo() all with the > same mutex and it still hangs. rtld-elf uses spinlocks in > areas that aren't called by dlfoo(). That doesn't say anything against what I've said. You haven't modified the JVM to not call pthreads unsafe operations over a potential involuntary context switch, without some method of preventing the context switch. Please see my quote from Chapter 12 of the Single UNIX Specification about how pthreads implementations are supposed serialize operations through unsafe operations themselves, instead of expecting the library to do it for them. You might as well serialize access to static buffers, as serialize access to non-threads reentrant system calls, if you are trying to make threads unsafe calls safe for threads. -- Terry From owner-freebsd-threads@FreeBSD.ORG Mon May 5 21:45:58 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 5E85637B404 for ; Mon, 5 May 2003 21:45:56 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1138C43F3F for ; Mon, 5 May 2003 21:45:56 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CuKr-0007Tj-00; Mon, 05 May 2003 21:45:50 -0700 Message-ID: <3EB73DA9.B0F0C647@mindspring.com> Date: Mon, 05 May 2003 21:44:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen , David Xu , threads@freebsd.org References: <3EB7256E.844A5958@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4506da5bbbb226c84d260680814129660387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 06 May 2003 04:45:58 -0000 > Daniel Eischen wrote: > > > Personally, I don't think this is justifiable, and that the > > > problem is actually a coding error in the threaded program, > > > with failure to comply with the POSIX and Single UNIX > > > Specification when writing your threaded program. The pthreads > > > documentation seems to back me up (Chapter 12 of "Go Solo 2", > > > as well as Corrigenda). > > > > It *is* an rtld-elf problem. I've protected dlfoo() all with the > > same mutex and it still hangs. rtld-elf uses spinlocks in > > areas that aren't called by dlfoo(). Rather than pointing at the standards over and over again, it occurs to me that I should ask you a question, instead, to emphasize our disconnect; so here it is: If my theory of operation for the bug was incorrect, can you tell me *why* my suggested scheduler workaround fixed it, instead of having no effect or only a partial effect? Thanks, -- Terry From owner-freebsd-threads@FreeBSD.ORG Mon May 5 22:54: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 B9C5237B401 for ; Mon, 5 May 2003 22:54:41 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03F2D43F3F for ; Mon, 5 May 2003 22:54:41 -0700 (PDT) (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 h465seBg011951; Tue, 6 May 2003 01:54:40 -0400 (EDT) Received: from localhost (eischen@localhost)h465saVR011942; Tue, 6 May 2003 01:54:38 -0400 (EDT) Date: Tue, 6 May 2003 01:54:36 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EB73DA9.B0F0C647@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: threads@freebsd.org Subject: Re: Patch for running Java2D demo (jdk-1.4.1p3_3) 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, 06 May 2003 05:54:42 -0000 On Mon, 5 May 2003, Terry Lambert wrote: > > Daniel Eischen wrote: > > > > Personally, I don't think this is justifiable, and that the > > > > problem is actually a coding error in the threaded program, > > > > with failure to comply with the POSIX and Single UNIX > > > > Specification when writing your threaded program. The pthreads > > > > documentation seems to back me up (Chapter 12 of "Go Solo 2", > > > > as well as Corrigenda). > > > > > > It *is* an rtld-elf problem. I've protected dlfoo() all with the > > > same mutex and it still hangs. rtld-elf uses spinlocks in > > > areas that aren't called by dlfoo(). > > Rather than pointing at the standards over and over again, it > occurs to me that I should ask you a question, instead, to > emphasize our disconnect; so here it is: > > If my theory of operation for the bug was incorrect, > can you tell me *why* my suggested scheduler workaround > fixed it, instead of having no effect or only a partial > effect? I'm assuming it is when a library/symbol is needed (not via dlopen()), rtld-elf goes off and does whatever it has to to find/load the symbol/library. It takes an internal read or write lock. Then whatever thread it was running in gets swapped out and another thread gets run. This thread perhaps causes other symbols to be referenced or perhaps does a dlopen() and causes the lock to be taken again. Read the rtld-elf source if you don't believe me. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon May 5 23:38:06 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 1360037B401; Mon, 5 May 2003 23:38:06 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9718443FCB; Mon, 5 May 2003 23:38:05 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h466c3Up076137; Mon, 5 May 2003 23:38:04 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <04ec01c3139a$579093d0$f001a8c0@davidw2k> From: "David Xu" To: "Julian Elischer" , "Daniel Eischen" References: Date: Tue, 6 May 2003 14:40:10 +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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 06:38:06 -0000 ----- Original Message -----=20 From: "Julian Elischer" To: "Daniel Eischen" Cc: Sent: Tuesday, May 06, 2003 8:39 AM Subject: Re: kern_threads.c.. upcall question.. >=20 >=20 > On Mon, 5 May 2003, Daniel Eischen wrote: >=20 > > On Mon, 5 May 2003, Julian Elischer wrote: > >=20 > > >=20 > > > In kern_threads.c, in function thread_export_context() > > > it first does a copyin() of the > > > context storage area. I think this is un-needed (and a complete = waste of > > > cycles) but I am not sure if there is some strange condition > > > regarding floating point registers or something that may want = this.. > > >=20 > > > Dan, Jon, David? > > > do any of you have a good reason why I shouldn't remove the = copyin().?? > >=20 > > Yeah, the threads library keeps the thread's active signal > > mask in the context area. The stack and flags may also > > be used in the context. > >=20 > > You should be able to safely copy out the mcontext without > > a copyin(). Is that what you're currently doing? Or is > > the entire context (ucontext) being exported? >=20 > it does: >=20 > *) copyin the ucontext_t >=20 > *) load context into it using thread_getcontext() which uses > get_mcontext() and adds the kernel thread sigmask (this must have > been added by jeff in some way) (note it doesn't OR, just writes) >=20 > *) copyout of the ucontext_t >=20 > The ucontext is: >=20 > sigset_t uc_sigmask; <-- gets over-written (!) > mcontext_t uc_mcontext; <-- gets over-written > struct __ucontext *uc_link; <-- one in userland MAY be > valuable > stack_t uc_stack; <-- probably worth saving.. > int uc_flags; <-- probably worth saving > int __spare__[4]; >=20 >=20 >=20 >=20 > It seems to me that just copying out the sigset_t and mcontext_t > may be all that is needed. (and I'm not so sure about the sigset_t > at that.. >=20 >=20 > >=20 > > --=20 > > Dan Eischen > >=20 > >=20 I think the following patch is enough: Index: kern_thread.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v retrieving revision 1.129 diff -u -r1.129 kern_thread.c --- kern_thread.c 1 May 2003 12:16:06 -0000 1.129 +++ kern_thread.c 6 May 2003 06:32:10 -0000 @@ -721,41 +721,6 @@ } =20 /* - * Fill a ucontext_t with a thread's context information. - * - * This is an analogue to getcontext(3). - */ -void -thread_getcontext(struct thread *td, ucontext_t *uc) -{ - - get_mcontext(td, &uc->uc_mcontext, 0); - PROC_LOCK(td->td_proc); - uc->uc_sigmask =3D td->td_sigmask; - PROC_UNLOCK(td->td_proc); -} - -/* - * Set a thread's context from a ucontext_t. - * - * This is an analogue to setcontext(3). - */ -int -thread_setcontext(struct thread *td, ucontext_t *uc) -{ - int ret; - - ret =3D set_mcontext(td, &uc->uc_mcontext); - if (ret =3D=3D 0) { - SIG_CANTMASK(uc->uc_sigmask); - PROC_LOCK(td->td_proc); - td->td_sigmask =3D uc->uc_sigmask; - PROC_UNLOCK(td->td_proc); - } - return (ret); -} - -/* * Initialize global thread allocation resources. */ void @@ -962,27 +927,25 @@ uintptr_t mbx; void *addr; int error,temp; - ucontext_t uc; + mcontext_t mc; =20 p =3D td->td_proc; kg =3D td->td_ksegrp; =20 /* Export the user/machine context. */ - addr =3D (void *)(&td->td_mailbox->tm_context); - error =3D copyin(addr, &uc, sizeof(ucontext_t)); - if (error)=20 - goto bad; - - thread_getcontext(td, &uc); - error =3D copyout(&uc, addr, sizeof(ucontext_t)); - if (error)=20 + get_mcontext(td, &mc, 0); + addr =3D (void *)(&td->td_mailbox->tm_context.uc_mcontext); + error =3D copyout(&mc, addr, sizeof(mcontext_t)); + if (error) goto bad; =20 /* Exports clock ticks in kernel mode */ addr =3D (caddr_t)(&td->td_mailbox->tm_sticks); temp =3D fuword(addr) + td->td_usticks; - if (suword(addr, temp)) + if (suword(addr, temp)) { + error =3D EFAULT; goto bad; + } =20 /* Get address in latest mbox of list pointer */ addr =3D (void *)(&td->td_mailbox->tm_next); And should we disable single threading testing or do double checking in thread_user_enter()? I think per-syscall PROC_LOCK is too expensive for us. David Xu From owner-freebsd-threads@FreeBSD.ORG Tue May 6 00:10: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 521C137B415; Tue, 6 May 2003 00:10:29 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9F9343F93; Tue, 6 May 2003 00:10:25 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc53) with ESMTP id <2003050607102505300puqibe>; Tue, 6 May 2003 07:10:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA33151; Tue, 6 May 2003 00:10:25 -0700 (PDT) Date: Tue, 6 May 2003 00:10:24 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <04ec01c3139a$579093d0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 07:10:34 -0000 On Tue, 6 May 2003, David Xu wrote: > I think the following patch is enough: I agree that this seems enough from what I was reading. (I like patches that have most lines starting with '-' :-) > > Index: kern_thread.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v > retrieving revision 1.129 > diff -u -r1.129 kern_thread.c > --- kern_thread.c 1 May 2003 12:16:06 -0000 1.129 > +++ kern_thread.c 6 May 2003 06:32:10 -0000 > @@ -721,41 +721,6 @@ [...] > void > @@ -962,27 +927,25 @@ > uintptr_t mbx; > void *addr; > int error,temp; > - ucontext_t uc; > + mcontext_t mc; > > p = td->td_proc; > kg = td->td_ksegrp; > > /* Export the user/machine context. */ > - addr = (void *)(&td->td_mailbox->tm_context); > - error = copyin(addr, &uc, sizeof(ucontext_t)); > - if (error) > - goto bad; > - > - thread_getcontext(td, &uc); > - error = copyout(&uc, addr, sizeof(ucontext_t)); > - if (error) > + get_mcontext(td, &mc, 0); I think this could be optimised even more. (why copy the FP regs if they are not valid) (etc). but it is an improvement.. > + addr = (void *)(&td->td_mailbox->tm_context.uc_mcontext); > + error = copyout(&mc, addr, sizeof(mcontext_t)); > + if (error) > goto bad; > > /* Exports clock ticks in kernel mode */ > addr = (caddr_t)(&td->td_mailbox->tm_sticks); > temp = fuword(addr) + td->td_usticks; > - if (suword(addr, temp)) > + if (suword(addr, temp)) { > + error = EFAULT; > goto bad; > + } > > /* Get address in latest mbox of list pointer */ > addr = (void *)(&td->td_mailbox->tm_next); > > > And should we disable single threading testing or do > double checking in thread_user_enter()? I think per-syscall > PROC_LOCK is too expensive for us. I am not sure which one you refer too.. Which single_threading test? BTW, I am a little unsure about the calling of thread_user_enter() from thread_userret(). > > David Xu > > > From owner-freebsd-threads@FreeBSD.ORG Tue May 6 00:25:48 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 DB8FF37B404; Tue, 6 May 2003 00:25:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3043543FBD; Tue, 6 May 2003 00:25:48 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h467PkUp081250; Tue, 6 May 2003 00:25:46 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001901c313a1$01c97c30$f001a8c0@davidw2k> From: "David Xu" To: "Julian Elischer" References: Date: Tue, 6 May 2003 15:27:52 +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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 07:25:50 -0000 ----- Original Message -----=20 From: "Julian Elischer" To: "David Xu" Cc: "Daniel Eischen" ; Sent: Tuesday, May 06, 2003 3:10 PM Subject: Re: kern_threads.c.. upcall question.. >=20 >=20 > On Tue, 6 May 2003, David Xu wrote: >=20 > > I think the following patch is enough: >=20 > I agree that this seems enough from what I was reading. > (I like patches that have most lines starting with '-' :-) >=20 >=20 > >=20 > > Index: kern_thread.c > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v > > retrieving revision 1.129 > > diff -u -r1.129 kern_thread.c > > --- kern_thread.c 1 May 2003 12:16:06 -0000 1.129 > > +++ kern_thread.c 6 May 2003 06:32:10 -0000 > > @@ -721,41 +721,6 @@ > [...] > > void > > @@ -962,27 +927,25 @@ > > uintptr_t mbx; > > void *addr; > > int error,temp; > > - ucontext_t uc; > > + mcontext_t mc; > > =20 > > p =3D td->td_proc; > > kg =3D td->td_ksegrp; > > =20 > > /* Export the user/machine context. */ > > - addr =3D (void *)(&td->td_mailbox->tm_context); > > - error =3D copyin(addr, &uc, sizeof(ucontext_t)); > > - if (error)=20 > > - goto bad; > > - > > - thread_getcontext(td, &uc); > > - error =3D copyout(&uc, addr, sizeof(ucontext_t)); > > - if (error)=20 > > + get_mcontext(td, &mc, 0); >=20 > I think this could be optimised even more. > (why copy the FP regs if they are not valid) (etc). > but it is an improvement.. >=20 Why need we an intermediate mcontext_t, why not direct copy the context in trap frame to userland space? This should be fastest. :-) > > + addr =3D (void *)(&td->td_mailbox->tm_context.uc_mcontext); > > + error =3D copyout(&mc, addr, sizeof(mcontext_t)); > > + if (error) > > goto bad; > > =20 > > /* Exports clock ticks in kernel mode */ > > addr =3D (caddr_t)(&td->td_mailbox->tm_sticks); > > temp =3D fuword(addr) + td->td_usticks; > > - if (suword(addr, temp)) > > + if (suword(addr, temp)) { > > + error =3D EFAULT; > > goto bad; > > + } > > =20 > > /* Get address in latest mbox of list pointer */ > > addr =3D (void *)(&td->td_mailbox->tm_next); > >=20 > >=20 > > And should we disable single threading testing or do > > double checking in thread_user_enter()? I think per-syscall > > PROC_LOCK is too expensive for us. >=20 > I am not sure which one you refer too.. Which single_threading > test? >=20 Single threading testing in thread_user_enter(), someone put=20 a PROC_LOCK, quoted here: /* =20 * First check that we shouldn't just abort. * But check if we are the single thread first! */ PROC_LOCK(p); if ((p->p_flag & P_SINGLE_EXIT) && (p->p_singlethread !=3D td)) = { mtx_lock_spin(&sched_lock); thread_stopped(p); thread_exit(); /* NOTREACHED */ } PROC_UNLOCK(p); > BTW, I am a little unsure about the calling of thread_user_enter() > from thread_userret(). >=20 This is quantum preemptive for userland, it is used when statclock interrupt hit in userland, if thread quantum is exhausted, it must unbind upcall from current thread, and schedule an upcall, you can think it is an implicit syscall triggered by CPU automatically which just means to swap out current thread. >=20 >=20 > >=20 > > David Xu > >=20 > >=20 > >=20 >=20 >=20 From owner-freebsd-threads@FreeBSD.ORG Tue May 6 00:30:53 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 B130837B404; Tue, 6 May 2003 00:30:53 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 819E743FBF; Tue, 6 May 2003 00:30:50 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc02) with ESMTP id <2003050607304900200nmfche>; Tue, 6 May 2003 07:30:49 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA33288; Tue, 6 May 2003 00:30:47 -0700 (PDT) Date: Tue, 6 May 2003 00:30:46 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <001901c313a1$01c97c30$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 07:30:54 -0000 On Tue, 6 May 2003, David Xu wrote: > > ----- Original Message ----- > From: "Julian Elischer" > To: "David Xu" > Cc: "Daniel Eischen" ; > Sent: Tuesday, May 06, 2003 3:10 PM > Subject: Re: kern_threads.c.. upcall question.. > > > > > > > > On Tue, 6 May 2003, David Xu wrote: > > > > > I think the following patch is enough: > > > > I agree that this seems enough from what I was reading. > > (I like patches that have most lines starting with '-' :-) > > > > > > > > > > Index: kern_thread.c > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v > > > retrieving revision 1.129 > > > diff -u -r1.129 kern_thread.c > > > --- kern_thread.c 1 May 2003 12:16:06 -0000 1.129 > > > +++ kern_thread.c 6 May 2003 06:32:10 -0000 > > > @@ -721,41 +721,6 @@ > > [...] > > > void > > > @@ -962,27 +927,25 @@ > > > uintptr_t mbx; > > > void *addr; > > > int error,temp; > > > - ucontext_t uc; > > > + mcontext_t mc; > > > > > > p = td->td_proc; > > > kg = td->td_ksegrp; > > > > > > /* Export the user/machine context. */ > > > - addr = (void *)(&td->td_mailbox->tm_context); > > > - error = copyin(addr, &uc, sizeof(ucontext_t)); > > > - if (error) > > > - goto bad; > > > - > > > - thread_getcontext(td, &uc); > > > - error = copyout(&uc, addr, sizeof(ucontext_t)); > > > - if (error) > > > + get_mcontext(td, &mc, 0); > > > > I think this could be optimised even more. > > (why copy the FP regs if they are not valid) (etc). > > but it is an improvement.. > > > > Why need we an intermediate mcontext_t, why not > direct copy the context in trap frame to userland space? > This should be fastest. :-) this is what I was thinking.. get_mcontext_user(td, addr) [...] > > > > > + addr = (void *)(&td->td_mailbox->tm_context.uc_mcontext); > > > + error = copyout(&mc, addr, sizeof(mcontext_t)); > > > + if (error) > > > goto bad; > > > > > > /* Exports clock ticks in kernel mode */ > > > addr = (caddr_t)(&td->td_mailbox->tm_sticks); > > > temp = fuword(addr) + td->td_usticks; > > > - if (suword(addr, temp)) > > > + if (suword(addr, temp)) { > > > + error = EFAULT; > > > goto bad; > > > + } > > > > > > /* Get address in latest mbox of list pointer */ > > > addr = (void *)(&td->td_mailbox->tm_next); > > > > > > > > > And should we disable single threading testing or do > > > double checking in thread_user_enter()? I think per-syscall > > > PROC_LOCK is too expensive for us. > > > > I am not sure which one you refer too.. Which single_threading > > test? > > > Single threading testing in thread_user_enter(), someone put > a PROC_LOCK, quoted here: > /* > * First check that we shouldn't just abort. > * But check if we are the single thread first! > */ > PROC_LOCK(p); > if ((p->p_flag & P_SINGLE_EXIT) && (p->p_singlethread != td)) { > mtx_lock_spin(&sched_lock); > thread_stopped(p); > thread_exit(); > /* NOTREACHED */ > } > PROC_UNLOCK(p); > > > BTW, I am a little unsure about the calling of thread_user_enter() > > from thread_userret(). > > > > This is quantum preemptive for userland, it is used when statclock > interrupt hit in userland, if thread quantum is exhausted, > it must unbind upcall from current thread, and schedule an upcall, > you can think it is an implicit syscall triggered by CPU automatically > which just means to swap out current thread. ah.. I was thinking that we could delay most of thread_user_enter() until we need it.. i.e why read the mailbox until we need it.. > > > > > > > > > > > David Xu > > > > > > > > > > > > > > > From owner-freebsd-threads@FreeBSD.ORG Tue May 6 00:40:27 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 3E2BD37B401; Tue, 6 May 2003 00:40:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C097E43F85; Tue, 6 May 2003 00:40:26 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h467ePUp081861; Tue, 6 May 2003 00:40:26 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <003001c313a3$0de7d500$f001a8c0@davidw2k> From: "David Xu" To: "Julian Elischer" References: Date: Tue, 6 May 2003 15:42:31 +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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 07:40:27 -0000 ----- Original Message -----=20 From: "Julian Elischer" To: "David Xu" Cc: ; "Daniel Eischen" Sent: Tuesday, May 06, 2003 3:30 PM Subject: Re: kern_threads.c.. upcall question.. >=20 >=20 > On Tue, 6 May 2003, David Xu wrote: >=20 > >=20 > > ----- Original Message -----=20 > > From: "Julian Elischer" > > To: "David Xu" > > Cc: "Daniel Eischen" ; = > > Sent: Tuesday, May 06, 2003 3:10 PM > > Subject: Re: kern_threads.c.. upcall question.. > >=20 > >=20 > > >=20 > > >=20 > > > On Tue, 6 May 2003, David Xu wrote: > > >=20 > > > > I think the following patch is enough: > > >=20 > > > I agree that this seems enough from what I was reading. > > > (I like patches that have most lines starting with '-' :-) > > >=20 > > >=20 > > > >=20 > > > > Index: kern_thread.c > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v > > > > retrieving revision 1.129 > > > > diff -u -r1.129 kern_thread.c > > > > --- kern_thread.c 1 May 2003 12:16:06 -0000 1.129 > > > > +++ kern_thread.c 6 May 2003 06:32:10 -0000 > > > > @@ -721,41 +721,6 @@ > > > [...] > > > > void > > > > @@ -962,27 +927,25 @@ > > > > uintptr_t mbx; > > > > void *addr; > > > > int error,temp; > > > > - ucontext_t uc; > > > > + mcontext_t mc; > > > > =20 > > > > p =3D td->td_proc; > > > > kg =3D td->td_ksegrp; > > > > =20 > > > > /* Export the user/machine context. */ > > > > - addr =3D (void *)(&td->td_mailbox->tm_context); > > > > - error =3D copyin(addr, &uc, sizeof(ucontext_t)); > > > > - if (error)=20 > > > > - goto bad; > > > > - > > > > - thread_getcontext(td, &uc); > > > > - error =3D copyout(&uc, addr, sizeof(ucontext_t)); > > > > - if (error)=20 > > > > + get_mcontext(td, &mc, 0); > > >=20 > > > I think this could be optimised even more. > > > (why copy the FP regs if they are not valid) (etc). > > > but it is an improvement.. > > >=20 > >=20 > > Why need we an intermediate mcontext_t, why not > > direct copy the context in trap frame to userland space? > > This should be fastest. :-) >=20 > this is what I was thinking.. > get_mcontext_user(td, addr) > [...] >=20 >=20 > >=20 > >=20 > > > > + addr =3D (void *)(&td->td_mailbox->tm_context.uc_mcontext); > > > > + error =3D copyout(&mc, addr, sizeof(mcontext_t)); > > > > + if (error) > > > > goto bad; > > > > =20 > > > > /* Exports clock ticks in kernel mode */ > > > > addr =3D (caddr_t)(&td->td_mailbox->tm_sticks); > > > > temp =3D fuword(addr) + td->td_usticks; > > > > - if (suword(addr, temp)) > > > > + if (suword(addr, temp)) { > > > > + error =3D EFAULT; > > > > goto bad; > > > > + } > > > > =20 > > > > /* Get address in latest mbox of list pointer */ > > > > addr =3D (void *)(&td->td_mailbox->tm_next); > > > >=20 > > > >=20 > > > > And should we disable single threading testing or do > > > > double checking in thread_user_enter()? I think per-syscall > > > > PROC_LOCK is too expensive for us. > > >=20 > > > I am not sure which one you refer too.. Which single_threading > > > test? > > >=20 > > Single threading testing in thread_user_enter(), someone put=20 > > a PROC_LOCK, quoted here: > > /* =20 > > * First check that we shouldn't just abort. > > * But check if we are the single thread first! > > */ > > PROC_LOCK(p); > > if ((p->p_flag & P_SINGLE_EXIT) && (p->p_singlethread !=3D = td)) { > > mtx_lock_spin(&sched_lock); > > thread_stopped(p); > > thread_exit(); > > /* NOTREACHED */ > > } > > PROC_UNLOCK(p); > >=20 > > > BTW, I am a little unsure about the calling of thread_user_enter() > > > from thread_userret(). > > >=20 > >=20 > > This is quantum preemptive for userland, it is used when statclock > > interrupt hit in userland, if thread quantum is exhausted, > > it must unbind upcall from current thread, and schedule an upcall, > > you can think it is an implicit syscall triggered by CPU = automatically > > which just means to swap out current thread. >=20 >=20 > ah.. > I was thinking that we could delay most of thread_user_enter() > until we need it.. > i.e why read the mailbox until we need it.. >=20 I think fuword is very fast, at least in i386, there is few instructions in fuword, please read its code in /sys/i386/i386/support.s, optimizing it may be not worth to do. Beside this, you can not fetch mailbox pointer on damand,=20 thread_schedule_upcall is protected under sched lock, it=20 can not handle page fault at that time, and kse_thr_interrupt need a mailbox pointer to indentify thread in kernel, delaying it will cause problem. From owner-freebsd-threads@FreeBSD.ORG Tue May 6 06:13:26 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 8AE1037B401; Tue, 6 May 2003 06:13:26 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B632543FD7; Tue, 6 May 2003 06:13:25 -0700 (PDT) (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 h46DDKBg011962; Tue, 6 May 2003 09:13:20 -0400 (EDT) Received: from localhost (eischen@localhost)h46DDJpd011959; Tue, 6 May 2003 09:13:19 -0400 (EDT) Date: Tue, 6 May 2003 09:13:19 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: kern_threads.c.. upcall question.. 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, 06 May 2003 13:13:26 -0000 On Tue, 6 May 2003, Julian Elischer wrote: > > On Tue, 6 May 2003, David Xu wrote: > > > > > > I think this could be optimised even more. > > > (why copy the FP regs if they are not valid) (etc). > > > but it is an improvement.. > > > > > > > Why need we an intermediate mcontext_t, why not > > direct copy the context in trap frame to userland space? > > This should be fastest. :-) > > this is what I was thinking.. > get_mcontext_user(td, addr) > [...] Don't break validation and setting of FP validity and type. get_mcontext() knows how to mark the validity of the FPU set and it's type (387 or SSE). The UTS relies on this information. Be very careful. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed May 7 13:08: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 E4A1F37B401; Wed, 7 May 2003 13:08:50 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 247C743FAF; Wed, 7 May 2003 13:08:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc53) with ESMTP id <2003050720084705300fc0q9e>; Wed, 7 May 2003 20:08:47 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA47642; Wed, 7 May 2003 13:08:47 -0700 (PDT) Date: Wed, 7 May 2003 13:08:46 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: David Xu Subject: Re: kern_threads.c.. upcall question.. 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, 07 May 2003 20:08:53 -0000 On Tue, 6 May 2003, Daniel Eischen wrote: > On Tue, 6 May 2003, Julian Elischer wrote: > > > > On Tue, 6 May 2003, David Xu wrote: > > > > > > > > > I think this could be optimised even more. > > > > (why copy the FP regs if they are not valid) (etc). > > > > but it is an improvement.. > > > > > > > > > > Why need we an intermediate mcontext_t, why not > > > direct copy the context in trap frame to userland space? > > > This should be fastest. :-) > > > > this is what I was thinking.. > > get_mcontext_user(td, addr) > > [...] > > Don't break validation and setting of FP validity and type. > get_mcontext() knows how to mark the validity of the FPU > set and it's type (387 or SSE). The UTS relies on this > information. Be very careful. Can you test david's simple patch that just removes the copy-in? We can wate til later to do the optimisations.. > > -- > Dan Eischen > > From owner-freebsd-threads@FreeBSD.ORG Wed May 7 13:16:14 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 6D46237B401; Wed, 7 May 2003 13:16:14 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A0143F3F; Wed, 7 May 2003 13:16:13 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <2003050720161100300bd147e>; Wed, 7 May 2003 20:16:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA47706; Wed, 7 May 2003 13:16:09 -0700 (PDT) Date: Wed, 7 May 2003 13:16:08 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <003001c313a3$0de7d500$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: kern_threads.c.. upcall question.. 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, 07 May 2003 20:16:14 -0000 On Tue, 6 May 2003, David Xu wrote: > > > > > > This is quantum preemptive for userland, it is used when statclock > > > interrupt hit in userland, if thread quantum is exhausted, > > > it must unbind upcall from current thread, and schedule an upcall, > > > you can think it is an implicit syscall triggered by CPU automatically > > > which just means to swap out current thread. > > > > > > ah.. > > I was thinking that we could delay most of thread_user_enter() > > until we need it.. > > i.e why read the mailbox until we need it.. > > > > I think fuword is very fast, at least in i386, there is > few instructions in fuword, please read its code in > /sys/i386/i386/support.s, optimizing it may be not worth to do. > Beside this, you can not fetch mailbox pointer on damand, > thread_schedule_upcall is protected under sched lock, it > can not handle page fault at that time, and kse_thr_interrupt > need a mailbox pointer to indentify thread in kernel, delaying > it will cause problem. Currently we cannot identify threads that are getting pagefaults or other reasons to enter the kernel except for syscall. I think there are probably ways that this can be optimised, but it is not important to do it now. > > > > From owner-freebsd-threads@FreeBSD.ORG Wed May 7 13:28:35 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 3DD4B37B401; Wed, 7 May 2003 13:28:35 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31FA643FA3; Wed, 7 May 2003 13:28:34 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc01) with ESMTP id <2003050720283200100rf69be>; Wed, 7 May 2003 20:28: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 NAA47779; Wed, 7 May 2003 13:28:31 -0700 (PDT) Date: Wed, 7 May 2003 13:28:30 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <001901c313a1$01c97c30$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen cc: John Baldwin Subject: Re: kern_threads.c.. lock question.. 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, 07 May 2003 20:28:35 -0000 On Tue, 6 May 2003, David Xu wrote: > > > > > > And should we disable single threading testing or do > > > double checking in thread_user_enter()? I think per-syscall > > > PROC_LOCK is too expensive for us. > > > > I am not sure which one you refer too.. Which single_threading > > test? > > > Single threading testing in thread_user_enter(), someone put > a PROC_LOCK, quoted here: > /* > * First check that we shouldn't just abort. > * But check if we are the single thread first! > */ > PROC_LOCK(p); > if ((p->p_flag & P_SINGLE_EXIT) && (p->p_singlethread != td)) { > mtx_lock_spin(&sched_lock); > thread_stopped(p); > thread_exit(); > /* NOTREACHED */ > } > PROC_UNLOCK(p); > I don't think that the lock should be needed.. The bit is set when another thread has decided to kill all other threads, and it will not be unset until all the other threads have been killed (including this one). The second clause (&& (p->p_singlethread != td)) is also realy un-needed as teh thread tha has called the single-threading condition should not have been able to go back to userland, and it is in fact suspended. (so I think it can never be true). This leaves us with: PROC_LOCK(p); if (p->p_flag & P_SINGLE_EXIT) { mtx_lock_spin(&sched_lock); thread_stopped(p); thread_exit(); /* NOTREACHED */ } PROC_UNLOCK(p); but either P_SINGLE_EXIT is set or it is not. if we miss the race we continue until we chack again later. (so what?) We can also guarantee that it will never be UNSET before we do call thread_exit() as that is the only condition that can clear it. (the thread_exit() of the last thread (except the one who called the singlthreading condition)) so I think it might be safe to cut this back to: if (p->p_flag & P_SINGLE_EXIT) { PROC_LOCK(p); mtx_lock_spin(&sched_lock); thread_stopped(p); thread_exit(); /* NOTREACHED */ } certainly it would be good to get this out of the path for every KSE syscall. From owner-freebsd-threads@FreeBSD.ORG Wed May 7 14:02:02 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 6FB5A37B401 for ; Wed, 7 May 2003 14:02:02 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id A160243F93 for ; Wed, 7 May 2003 14:02:00 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11061 invoked from network); 7 May 2003 21:02:08 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 7 May 2003 21:02:08 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h47L1rp0006132; Wed, 7 May 2003 17:01:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) 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: Wed, 07 May 2003 17:01:52 -0400 (EDT) From: John Baldwin To: Julian Elischer cc: threads@freebsd.org cc: Daniel Eischen cc: David Xu Subject: Re: kern_threads.c.. lock question.. 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, 07 May 2003 21:02:02 -0000 On 07-May-2003 Julian Elischer wrote: > > > On Tue, 6 May 2003, David Xu wrote: > >> > > >> > > And should we disable single threading testing or do >> > > double checking in thread_user_enter()? I think per-syscall >> > > PROC_LOCK is too expensive for us. >> > >> > I am not sure which one you refer too.. Which single_threading >> > test? >> > >> Single threading testing in thread_user_enter(), someone put >> a PROC_LOCK, quoted here: >> /* >> * First check that we shouldn't just abort. >> * But check if we are the single thread first! >> */ >> PROC_LOCK(p); >> if ((p->p_flag & P_SINGLE_EXIT) && (p->p_singlethread != td)) { >> mtx_lock_spin(&sched_lock); >> thread_stopped(p); >> thread_exit(); >> /* NOTREACHED */ >> } >> PROC_UNLOCK(p); >> > > I don't think that the lock should be needed.. > The bit is set when another thread has decided to kill all other > threads, and it will not be unset until all the other threads have been > killed (including this one). The second clause (&& (p->p_singlethread != > td)) is also realy un-needed as teh thread tha has called the > single-threading condition should not have been able to go back to > userland, and it is in fact suspended. (so I think it can never be > true). I thought singlethreading only suspended other threads and that they can be resumed later if need be. I suppose in that case you wouldn't use P_SINGLE_EXIT though. > This leaves us with: > PROC_LOCK(p); > if (p->p_flag & P_SINGLE_EXIT) { > mtx_lock_spin(&sched_lock); > thread_stopped(p); > thread_exit(); > /* NOTREACHED */ > } > PROC_UNLOCK(p); > > but either P_SINGLE_EXIT is set or it is not. > if we miss the race we continue until we chack again later. (so what?) > We can also guarantee that it will never be UNSET before we do call > thread_exit() as that is the only condition that can clear it. > (the thread_exit() of the last thread (except the one who called the > singlthreading condition)) > > > so I think it might be safe to cut this back to: > if (p->p_flag & P_SINGLE_EXIT) { > PROC_LOCK(p); > mtx_lock_spin(&sched_lock); > thread_stopped(p); > thread_exit(); > /* NOTREACHED */ > } > > certainly it would be good to get this out of the path for every KSE > syscall. Please let's optimize later and get things working _first_. Right now current has this really annoying piss-ant of a bug where I lose my keyboard every so often in X, probably due to a locking bug I haven't managed to track down yet (feels an awful lot like a lost wakeup). If you want to remove the p_singlethread check, that is fine. Part of the reason I put the lock there was so that the check of multiple values would at least get a consistent snapshot to work with when making its decision. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-threads@FreeBSD.ORG Wed May 7 14:51:07 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 55B4D37B401; Wed, 7 May 2003 14:51:07 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12C9643F3F; Wed, 7 May 2003 14:51:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <2003050721510200300bfj1fe>; Wed, 7 May 2003 21:51:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA48337; Wed, 7 May 2003 14:51:00 -0700 (PDT) Date: Wed, 7 May 2003 14:50:59 -0700 (PDT) From: Julian Elischer To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen cc: David Xu Subject: Re: kern_threads.c.. lock question.. 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, 07 May 2003 21:51:07 -0000 On Wed, 7 May 2003, John Baldwin wrote: > > On 07-May-2003 Julian Elischer wrote: > > > > > > On Tue, 6 May 2003, David Xu wrote: > I thought singlethreading only suspended other threads and that > they can be resumed later if need be. I suppose in that case > you wouldn't use P_SINGLE_EXIT though. exactly. "single thread yourself by means of murdering all the competition" > > > Please let's optimize later and get things working _first_. > Right now current has this really annoying piss-ant of a bug > where I lose my keyboard every so often in X, probably due to > a locking bug I haven't managed to track down yet (feels an > awful lot like a lost wakeup). Its not anything urgent.. it just came up in conversation with david.. I'm not in a hurry to change it. certainly not before 5.1. (It only affects KSE processes anyhow) What we were actually discussing was a potential corruption of the KSE sigmask in userland. This was just something we noticed while passing through.. From owner-freebsd-threads@FreeBSD.ORG Wed May 7 14:57:39 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 8EE2937B401 for ; Wed, 7 May 2003 14:57:39 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CC243F75 for ; Wed, 7 May 2003 14:57:38 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc02) with ESMTP id <20030507215737002006tj71e>; Wed, 7 May 2003 21:57:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA48383 for ; Wed, 7 May 2003 14:57:37 -0700 (PDT) Date: Wed, 7 May 2003 14:57:36 -0700 (PDT) From: Julian Elischer To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: the elf loader problem.. 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, 07 May 2003 21:57:39 -0000 I just deleted the email in question unfortunatly, so I have to ask.. who was looking at this problem? From owner-freebsd-threads@FreeBSD.ORG Wed May 7 15:35: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 5176137B401 for ; Wed, 7 May 2003 15:35:18 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 724D143F75 for ; Wed, 7 May 2003 15:35:17 -0700 (PDT) (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 h47MZABg008053; Wed, 7 May 2003 18:35:10 -0400 (EDT) Received: from localhost (eischen@localhost)h47MZAgH008050; Wed, 7 May 2003 18:35:10 -0400 (EDT) Date: Wed, 7 May 2003 18:35:10 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: the elf loader problem.. 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, 07 May 2003 22:35:18 -0000 On Wed, 7 May 2003, Julian Elischer wrote: > > I just deleted the email in question unfortunatly, so I have to ask.. You can browse/search the email archives now (since we moved to an @freebsd.org list). > who was looking at this problem? It was Alexander Kabaev It would be really nice to get this fixed before the release... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed May 7 16:23:08 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 DA50837B401; Wed, 7 May 2003 16:23:08 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C6743F75; Wed, 7 May 2003 16:23:06 -0700 (PDT) (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 h47NN4Up028971; Wed, 7 May 2003 16:23:05 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <003701c314f0$0dbad340$0701a8c0@tiger> From: "David Xu" To: "Julian Elischer" References: Date: Thu, 8 May 2003 07:26:13 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: threads@freebsd.org cc: Daniel Eischen cc: John Baldwin Subject: Re: kern_threads.c.. lock question.. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 23:23:09 -0000 ----- Original Message -----=20 From: "Julian Elischer" To: "David Xu" Cc: ; "Daniel Eischen" ; = "John Baldwin" Sent: Thursday, May 08, 2003 4:28 AM Subject: Re: kern_threads.c.. lock question.. > >=20 > so I think it might be safe to cut this back to: > if (p->p_flag & P_SINGLE_EXIT) { =20 > PROC_LOCK(p); > mtx_lock_spin(&sched_lock); > thread_stopped(p); > thread_exit(); > /* NOTREACHED */ > } >=20 > certainly it would be good to get this out of the path for every KSE > syscall. >=20 I like these code. David Xu From owner-freebsd-threads@FreeBSD.ORG Wed May 7 16:34:49 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 C59E237B401; Wed, 7 May 2003 16:34:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6747443F3F; Wed, 7 May 2003 16:34:49 -0700 (PDT) (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 h47NYlUp029323; Wed, 7 May 2003 16:34:48 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <004301c314f1$b0b67fd0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: Date: Thu, 8 May 2003 07:37:56 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: libpthread_init X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 23:34:50 -0000 CCed freebsd-threads@freebsd.org ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Sent: Wednesday, May 07, 2003 8:22 PM Subject: Re: libpthread_init > On Wed, 7 May 2003, David Xu wrote: >=20 > > Is it possible to call libpthread_init in libc at > > startup to initialize libpthread for static linked > > binary?=20 > > for example, use "__attribute__((constructor))" > > or put a weak symbol in crt1.c to let libpthread > > override it, and be called in libc startup routine? >=20 > I don't know. It would be nice to get rid of all the > calls to lipbthread_init() in libpthread. >=20 I think there should be a weak symbol in crt1.c or somewhere to let static linked thread library overide it, the weak symbol will be = called at libc startup time to initialize thread library . I don't like current thread initializing mode --- it is triggered by user application, and = the initializing point is not clear, where and when is it initialized? It is error-prone mode, while mono-thread has a perfect initializing = step, why should threaded app have a bad initializing step, and we must put : "if (!__isthreaded) then do something" everywhere in thread = library, I have already found that a simple "write(1, "hello", 5)" would cause = SEGSIGV when it is linked with static pthread library. FreeBSD now has two mode = apps, mono-threaded and mutli-threaded, I think both should have a good = initializing code, both are important, libc should be refined to reflect the fact. > --=20 > Dan Eischen >=20 >=20 From owner-freebsd-threads@FreeBSD.ORG Wed May 7 18:05:08 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 6AE7437B401 for ; Wed, 7 May 2003 18:05:08 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB03C43F93 for ; Wed, 7 May 2003 18:05:07 -0700 (PDT) (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 h48155Bg003541; Wed, 7 May 2003 21:05:06 -0400 (EDT) Received: from localhost (eischen@localhost)h48153m8003524; Wed, 7 May 2003 21:05:04 -0400 (EDT) Date: Wed, 7 May 2003 21:05:03 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <004301c314f1$b0b67fd0$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: libpthread_init 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, 08 May 2003 01:05:08 -0000 On Thu, 8 May 2003, David Xu wrote: > CCed freebsd-threads@freebsd.org > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Sent: Wednesday, May 07, 2003 8:22 PM > Subject: Re: libpthread_init > > > > On Wed, 7 May 2003, David Xu wrote: > > > > > Is it possible to call libpthread_init in libc at > > > startup to initialize libpthread for static linked > > > binary? > > > for example, use "__attribute__((constructor))" > > > or put a weak symbol in crt1.c to let libpthread > > > override it, and be called in libc startup routine? > > > > I don't know. It would be nice to get rid of all the > > calls to lipbthread_init() in libpthread. > > > > I think there should be a weak symbol in crt1.c or somewhere > to let static linked thread library overide it, the weak symbol will be called > at libc startup time to initialize thread library . I don't like current > thread initializing mode --- it is triggered by user application, and the > initializing point is not clear, where and when is it initialized? I know. I brought this up years ago, but didn't really know how to fix it. > It is error-prone mode, while mono-thread has a perfect initializing step, > why should threaded app have a bad initializing step, and we must > put : "if (!__isthreaded) then do something" everywhere in thread library, I know, I know :-) You're preaching to the choir! (I agree) > I have already found that a simple "write(1, "hello", 5)" would cause SEGSIGV > when it is linked with static pthread library. FreeBSD now has two mode apps, > mono-threaded and mutli-threaded, I think both should have a good initializing > code, both are important, libc should be refined to reflect the fact. Yes. Have you tried it to see if it works? The other thread libraries would also need to be updated. We should use a common symbol like __thread_init() or __libc_thread_init() so they can all override the same symbol. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed May 7 18:12:32 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 E1DBC37B401; Wed, 7 May 2003 18:12:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6883943FAF; Wed, 7 May 2003 18:12:32 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h481CUUp039650; Wed, 7 May 2003 18:12:31 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <005d01c314ff$32b737b0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Thu, 8 May 2003 09:14:37 +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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: libpthread_init 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, 08 May 2003 01:12:33 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Thursday, May 08, 2003 9:05 AM Subject: Re: libpthread_init > On Thu, 8 May 2003, David Xu wrote: >=20 > > CCed freebsd-threads@freebsd.org > >=20 > > ----- Original Message -----=20 > > From: "Daniel Eischen" > > To: "David Xu" > > Sent: Wednesday, May 07, 2003 8:22 PM > > Subject: Re: libpthread_init > >=20 > >=20 > > > On Wed, 7 May 2003, David Xu wrote: > > >=20 > > > > Is it possible to call libpthread_init in libc at > > > > startup to initialize libpthread for static linked > > > > binary?=20 > > > > for example, use "__attribute__((constructor))" > > > > or put a weak symbol in crt1.c to let libpthread > > > > override it, and be called in libc startup routine? > > >=20 > > > I don't know. It would be nice to get rid of all the > > > calls to lipbthread_init() in libpthread. > > >=20 > >=20 > > I think there should be a weak symbol in crt1.c or somewhere > > to let static linked thread library overide it, the weak symbol = will be called > > at libc startup time to initialize thread library . I don't like = current > > thread initializing mode --- it is triggered by user application, = and the > > initializing point is not clear, where and when is it initialized? >=20 > I know. I brought this up years ago, but didn't really > know how to fix it. >=20 > > It is error-prone mode, while mono-thread has a perfect initializing = step, > > why should threaded app have a bad initializing step, and we must > > put : "if (!__isthreaded) then do something" everywhere in thread = library, >=20 > I know, I know :-) You're preaching to the choir! (I agree) >=20 > > I have already found that a simple "write(1, "hello", 5)" would = cause SEGSIGV > > when it is linked with static pthread library. FreeBSD now has two = mode apps, > > mono-threaded and mutli-threaded, I think both should have a good = initializing > > code, both are important, libc should be refined to reflect the = fact. >=20 > Yes. Have you tried it to see if it works? The other thread > libraries would also need to be updated. We should use a common > symbol like __thread_init() or __libc_thread_init() so they can > all override the same symbol. >=20 This is what I want to see, neat code. :-) I will try to see if I can work out a patch. > --=20 > Dan Eischen >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-threads@FreeBSD.ORG Thu May 8 06:56:48 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 B253237B401; Thu, 8 May 2003 06:56:48 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A028F43F3F; Thu, 8 May 2003 06:56:47 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h48Dui3D027288; Thu, 8 May 2003 09:56:44 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h48Duiti027287; Thu, 8 May 2003 09:56:44 -0400 (EDT) Date: Thu, 8 May 2003 09:56:44 -0400 From: Alexander Kabaev To: "David Xu" Message-Id: <20030508095644.06571486.ak03@gte.com> In-Reply-To: <005d01c314ff$32b737b0$f001a8c0@davidw2k> References: <005d01c314ff$32b737b0$f001a8c0@davidw2k> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: libpthread_init 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, 08 May 2003 13:56:49 -0000 On Thu, 8 May 2003 09:14:37 +0800 "David Xu" wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Thursday, May 08, 2003 9:05 AM > Subject: Re: libpthread_init > > > I know. I brought this up years ago, but didn't really > > know how to fix it. > > > > > It is error-prone mode, while mono-thread has a perfect > > > initializing step, why should threaded app have a bad initializing > > > step, and we must put : "if (!__isthreaded) then do something" > > > everywhere in thread library, > > > > I know, I know :-) You're preaching to the choir! (I agree) > > > > > I have already found that a simple "write(1, "hello", 5)" would > > > cause SEGSIGV when it is linked with static pthread library. > > > FreeBSD now has two mode apps, mono-threaded and mutli-threaded, > > > I think both should have a good initializing code, both are > > > important, libc should be refined to reflect the fact. > > > > Yes. Have you tried it to see if it works? The other thread > > libraries would also need to be updated. We should use a common > > symbol like __thread_init() or __libc_thread_init() so they can > > all override the same symbol. > > > > This is what I want to see, neat code. :-) > I will try to see if I can work out a patch. So what is wrong with __attribute__((constructor)) again? -- Alexander Kabaev From owner-freebsd-threads@FreeBSD.ORG Thu May 8 07:35:37 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 CDF0937B404; Thu, 8 May 2003 07:35:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 102EB43FA3; Thu, 8 May 2003 07:35:35 -0700 (PDT) (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 h48EZSUp059952; Thu, 8 May 2003 07:35:31 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <002b01c3156f$86209020$0701a8c0@tiger> From: "David Xu" To: "Alexander Kabaev" References: <005d01c314ff$32b737b0$f001a8c0@davidw2k> <20030508095644.06571486.ak03@gte.com> Date: Thu, 8 May 2003 22:38:37 +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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: libpthread_init X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 14:35:38 -0000 ----- Original Message -----=20 From: "Alexander Kabaev" To: "David Xu" Cc: "Daniel Eischen" ; = Sent: Thursday, May 08, 2003 9:56 PM Subject: Re: libpthread_init > On Thu, 8 May 2003 09:14:37 +0800 > "David Xu" wrote: >=20 > >=20 > > ----- Original Message -----=20 > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Thursday, May 08, 2003 9:05 AM > > Subject: Re: libpthread_init > >=20 > > > I know. I brought this up years ago, but didn't really > > > know how to fix it. > > >=20 > > > > It is error-prone mode, while mono-thread has a perfect > > > > initializing step, why should threaded app have a bad = initializing > > > > step, and we must put : "if (!__isthreaded) then do something" > > > > everywhere in thread library, > > >=20 > > > I know, I know :-) You're preaching to the choir! (I agree) > > >=20 > > > > I have already found that a simple "write(1, "hello", 5)" would > > > > cause SEGSIGV when it is linked with static pthread library. > > > > FreeBSD now has two mode apps, mono-threaded and mutli-threaded, = > > > > I think both should have a good initializing code, both are > > > > important, libc should be refined to reflect the fact. > > >=20 > > > Yes. Have you tried it to see if it works? The other thread > > > libraries would also need to be updated. We should use a common > > > symbol like __thread_init() or __libc_thread_init() so they can > > > all override the same symbol. > > >=20 > >=20 > > This is what I want to see, neat code. :-) > > I will try to see if I can work out a patch. >=20 > So what is wrong with __attribute__((constructor)) again? >=20 It does not work for archive version of thread library. > --=20 > Alexander Kabaev > _______________________________________________ > 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" >=20