From owner-freebsd-threads@FreeBSD.ORG Sun Apr 27 04:53:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F167637B401; Sun, 27 Apr 2003 04:53:18 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3EDE43FBF; Sun, 27 Apr 2003 04:53:17 -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 h3RBrGUp011056; Sun, 27 Apr 2003 04:53:17 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <000e01c30cb4$30289b40$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: <006501c30c5f$77fe5950$0701a8c0@tiger> Date: Sun, 27 Apr 2003 19:57:32 +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: pthread_join 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: Sun, 27 Apr 2003 11:53:25 -0000 I found I can not get the following race fixed: Thread A is a joiner of thread B, thread C calls pthread_cancel on A, because of multipile scheduler locks, I can not get the race fixed.=20 Is it possible we just use a single scheduler lock to simplify things a = bit? David From owner-freebsd-threads@FreeBSD.ORG Sun Apr 27 08:02:09 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 6BE0837B401 for ; Sun, 27 Apr 2003 08:02:09 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4A1143F85 for ; Sun, 27 Apr 2003 08:02:08 -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 h3RF27Bg022218; Sun, 27 Apr 2003 11:02:07 -0400 (EDT) Received: from localhost (eischen@localhost)h3RF255o022202; Sun, 27 Apr 2003 11:02:07 -0400 (EDT) Date: Sun, 27 Apr 2003 11:02:05 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <000e01c30cb4$30289b40$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: pthread_join 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, 27 Apr 2003 15:02:09 -0000 On Sun, 27 Apr 2003, David Xu wrote: > I found I can not get the following race fixed: > Thread A is a joiner of thread B, thread C calls pthread_cancel on A, > because of multipile scheduler locks, I can not get the race fixed. > Is it possible we just use a single scheduler lock to simplify things a bit? Hmm, you mean if thread A is already joined on B? I don't see the race. Everything looks right. We don't take multiple scheduling locks at the same time, so everything should work. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 27 17:08:12 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 222A537B401; Sun, 27 Apr 2003 17:08:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6A8A43F3F; Sun, 27 Apr 2003 17:08:11 -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 h3S087Up077820; Sun, 27 Apr 2003 17:08:08 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <007401c30d1a$da3d7f40$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" , "David Xu" References: Date: Mon, 28 Apr 2003 08:12:24 +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: pthread_join 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, 28 Apr 2003 00:08:12 -0000 In thr_cleanup(), joinee accesses joiner without holding joiner's sched = lock, it is possible when joinee accesses joiner, the joiner may disappear = (canceled). if ((joiner->state =3D=3D PS_JOIN) && (joiner->join_status.thread =3D=3D thread)) { joiner->join_status.thread =3D NULL; David Xu ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Sunday, April 27, 2003 11:02 PM Subject: Re: pthread_join > On Sun, 27 Apr 2003, David Xu wrote: > > I found I can not get the following race fixed: > > Thread A is a joiner of thread B, thread C calls pthread_cancel on = A, > > because of multipile scheduler locks, I can not get the race fixed. = > > Is it possible we just use a single scheduler lock to simplify = things a bit? >=20 > Hmm, you mean if thread A is already joined on B? I don't see the > race. Everything looks right. We don't take multiple scheduling > locks at the same time, so everything should work. >=20 > --=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 Apr 27 21:58:20 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 EEA0437B401 for ; Sun, 27 Apr 2003 21:58:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44FBD43FB1 for ; Sun, 27 Apr 2003 21:58:20 -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 h3S4wJBg018152; Mon, 28 Apr 2003 00:58:19 -0400 (EDT) Received: from localhost (eischen@localhost)h3S4wHNi018148; Mon, 28 Apr 2003 00:58:19 -0400 (EDT) Date: Mon, 28 Apr 2003 00:58:17 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <007401c30d1a$da3d7f40$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: pthread_join 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, 28 Apr 2003 04:58:21 -0000 On Mon, 28 Apr 2003, David Xu wrote: > In thr_cleanup(), joinee accesses joiner without holding joiner's sched lock, > it is possible when joinee accesses joiner, the joiner may disappear (canceled). > > if ((joiner->state == PS_JOIN) && > (joiner->join_status.thread == thread)) { > joiner->join_status.thread = NULL; Yes, when canceling we need to take the joinee's scheduling lock. I think we need to add a reference to the thread so it doesn't go away while we release the current lock and take the joiner's lock. I think processing the joiner can be done in pthread_exit() instead of thr_cleanup(). That's the way libc_r does it; I moved it into thr_kern in libpthread, but it doesn't need to be there. We could also have another lock just for joins. Or use each thread's lock. Each thread has a lock, similar to proc lock in the kernel, but they're not currently used for anything yet. I envisioned using the proc lock whenever we needed to modify something in the thread, but just used the scheduling locks because it was easier. I'm working on some signal fixes and some other fixes to hopefully fix your SMP problems. I want to try these fixes before making _thr_sched_switch() atomic (your SMP changes). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 00:39: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 0C62E37B401 for ; Mon, 28 Apr 2003 00:39:32 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CD2C43F75 for ; Mon, 28 Apr 2003 00:39:30 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JM649LCP; Mon, 28 Apr 2003 15:24:54 +0800 Message-ID: <001001c30d59$913d25e0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Mon, 28 Apr 2003 15:38:19 +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: pthread_join 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, 28 Apr 2003 07:39:32 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Monday, April 28, 2003 12:58 PM Subject: Re: pthread_join > On Mon, 28 Apr 2003, David Xu wrote: >=20 > > In thr_cleanup(), joinee accesses joiner without holding joiner's = sched lock, > > it is possible when joinee accesses joiner, the joiner may disappear = (canceled). > >=20 > > if ((joiner->state =3D=3D PS_JOIN) && > > (joiner->join_status.thread =3D=3D thread)) { > > joiner->join_status.thread =3D NULL; >=20 > Yes, when canceling we need to take the joinee's scheduling lock. > I think we need to add a reference to the thread so it doesn't go > away while we release the current lock and take the joiner's lock. > I think processing the joiner can be done in pthread_exit() instead > of thr_cleanup(). That's the way libc_r does it; I moved it > into thr_kern in libpthread, but it doesn't need to be there. >=20 > We could also have another lock just for joins. Or use each > thread's lock. Each thread has a lock, similar to proc lock > in the kernel, but they're not currently used for anything yet. > I envisioned using the proc lock whenever we needed to modify > something in the thread, but just used the scheduling locks > because it was easier. >=20 > I'm working on some signal fixes and some other fixes to > hopefully fix your SMP problems. I want to try these fixes > before making _thr_sched_switch() atomic (your SMP changes). >=20 My change to atomic _thr_sched_switch does not add overhead, it just enters critical region ealier than current code, but total number of lock and critical region is same as current code, and gains reliable result. > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 06:57: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 A193C37B401; Mon, 28 Apr 2003 06:57:57 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 749EF43FB1; Mon, 28 Apr 2003 06:57:52 -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 h3SDvnUp080339; Mon, 28 Apr 2003 06:57:51 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001501c30d8e$c1aca4a0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: <3EAACB08.BFD0B8F5@mindspring.com> Date: Mon, 28 Apr 2003 22:02:05 +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: SMPing libpthread 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, 28 Apr 2003 13:57:58 -0000 I have updated the libpthread SMP patch. http://people.freebsd.org/~davidxu/libpthread_smp.diff default is SMP enabled in the patch. the patch past all ACE tests, also crew program was tested. David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 13:48:24 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 165C237B401 for ; Mon, 28 Apr 2003 13:48:24 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B2643FB1 for ; Mon, 28 Apr 2003 13:48:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003042820482200200o0m6ge>; Mon, 28 Apr 2003 20:48:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA45994; Mon, 28 Apr 2003 13:48:22 -0700 (PDT) Date: Mon, 28 Apr 2003 13:48:21 -0700 (PDT) From: Julian Elischer To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Vallo Kallaste Subject: Re: libkse report (fwd) 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, 28 Apr 2003 20:48:24 -0000 Quite a positive report.. Maybe if the latest patches are checked in, it may even do better. ---------- Forwarded message ---------- Date: Mon, 28 Apr 2003 23:08:56 +0300 From: Vallo Kallaste To: Julian Elischer Subject: Re: libthr broken On Sun, Apr 27, 2003 at 01:47:09PM -0700, Julian Elischer wrote: > THEORETICALLY it should be as simple as this: > > cd /usr/src/lib/libpthread > make > make install. (will install as libkse at this time) > cd /usr/lib > mv libc_r.so.xx libc_r.so.xx.hold > mv libkse.so.?? libc_r.so.xx KNode works and it seems the bug I had with libthr is gone. It has other problems, however, which I never had before. For some reason KNode thinks, after I've saved newly composed text to tempfile, that external editor is still running and no text is transferred from tempfile to KNode own editor window. KNode process remains in memory after closing, taking some 24MB of memory. Mozilla and Phoenix will not start up any window, they're show up in top listing, take usual amount of memory and are not killable by TERM signal, only SIGKILL. But overall, libpthread (libkse) is in better shape than I thought. The fact that KDE got up and KNode is usable, is quite a wonder. -- Vallo Kallaste From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 14:03:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7321E37B401 for ; Mon, 28 Apr 2003 14:03:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 841EF43F3F for ; Mon, 28 Apr 2003 14:03:35 -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 h3SL3QBg011303; Mon, 28 Apr 2003 17:03:26 -0400 (EDT) Received: from localhost (eischen@localhost)h3SL3QFo011300; Mon, 28 Apr 2003 17:03:26 -0400 (EDT) Date: Mon, 28 Apr 2003 17:03:26 -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: Vallo Kallaste Subject: Re: libkse report (fwd) 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, 28 Apr 2003 21:03:36 -0000 On Mon, 28 Apr 2003, Julian Elischer wrote: > Quite a positive report.. > Maybe if the latest patches are checked in, it may even do better. Yup, I'm working on it. Should be sometime today. BTW, mozilla worked for me after the first set of changes. I'll have to try it again now that I have access again to the machine with it installed. > > ---------- Forwarded message ---------- > Date: Mon, 28 Apr 2003 23:08:56 +0300 > From: Vallo Kallaste > To: Julian Elischer > Subject: Re: libthr broken > > On Sun, Apr 27, 2003 at 01:47:09PM -0700, Julian Elischer > wrote: > > > THEORETICALLY it should be as simple as this: > > > > cd /usr/src/lib/libpthread > > make > > make install. (will install as libkse at this time) > > cd /usr/lib > > mv libc_r.so.xx libc_r.so.xx.hold > > mv libkse.so.?? libc_r.so.xx > > KNode works and it seems the bug I had with libthr is gone. It has > other problems, however, which I never had before. For some reason > KNode thinks, after I've saved newly composed text to tempfile, that > external editor is still running and no text is transferred from > tempfile to KNode own editor window. KNode process remains in memory > after closing, taking some 24MB of memory. Mozilla and Phoenix will > not start up any window, they're show up in top listing, take usual > amount of memory and are not killable by TERM signal, only SIGKILL. > But overall, libpthread (libkse) is in better shape than I thought. > The fact that KDE got up and KNode is usable, is quite a wonder. > -- > > Vallo Kallaste -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 16:59: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 51B8137B401 for ; Mon, 28 Apr 2003 16:59:58 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DA3B43F75 for ; Mon, 28 Apr 2003 16:59: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 h3SNxuBg009062; Mon, 28 Apr 2003 19:59:56 -0400 (EDT) Received: from localhost (eischen@localhost)h3SNxsra009056; Mon, 28 Apr 2003 19:59:56 -0400 (EDT) Date: Mon, 28 Apr 2003 19:59:54 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <001501c30d8e$c1aca4a0$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread 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, 28 Apr 2003 23:59:58 -0000 On Mon, 28 Apr 2003, David Xu wrote: > I have updated the libpthread SMP patch. > http://people.freebsd.org/~davidxu/libpthread_smp.diff > default is SMP enabled in the patch. the patch past all ACE tests, > also crew program was tested. Committed. I also made spinlock/spinunlock critical regions. Take a look at it and see if you think it'll work OK. All my tests pass with this. We still have a problem with mozilla. When I first got libkse working, mozilla worked for me but now it hangs upon startup (no window ever gets displayed). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 19:12:04 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 D686037B401; Mon, 28 Apr 2003 19:12:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA4E43FA3; Mon, 28 Apr 2003 19:12:04 -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 h3T2C3Up035352; Mon, 28 Apr 2003 19:12:03 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <006101c30df5$00438740$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Tue, 29 Apr 2003 10:08:34 +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: SMPing libpthread 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, 29 Apr 2003 02:12:05 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Tuesday, April 29, 2003 7:59 AM Subject: Re: SMPing libpthread > On Mon, 28 Apr 2003, David Xu wrote: >=20 > > I have updated the libpthread SMP patch. > > http://people.freebsd.org/~davidxu/libpthread_smp.diff > > default is SMP enabled in the patch. the patch past all ACE tests, > > also crew program was tested. >=20 > Committed. I also made spinlock/spinunlock critical regions. > Take a look at it and see if you think it'll work OK. All > my tests pass with this. >=20 I found some DNS routines are using spinlock! so they may be blocked in network transaction, it would lock out our scheduler. I think we still need to rescure PS_SPINBLOCK code from libc_r. > We still have a problem with mozilla. When I first got > libkse working, mozilla worked for me but now it hangs > upon startup (no window ever gets displayed). >=20 Can you use gdb and press ctrl+c to see where it is dead loop? > --=20 > Dan Eischen >=20 David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 19:22: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 3A30B37B401; Mon, 28 Apr 2003 19:22:02 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B1A43F75; Mon, 28 Apr 2003 19:22:01 -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 h3T2M0Bg000726; Mon, 28 Apr 2003 22:22:00 -0400 (EDT) Received: from localhost (eischen@localhost)h3T2LxpJ000711; Mon, 28 Apr 2003 22:21:59 -0400 (EDT) Date: Mon, 28 Apr 2003 22:21:59 -0400 (EDT) From: Daniel Eischen To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jdp@freebsd.org Subject: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 02:22:02 -0000 So I was glancing at rltd-elf, specifically lockdflt.c. There seems to be an assumption that sigprocmask() can be used to protect a thread from being swapped out. Am I reading this right? There are no such guarantees with libpthread. A thread will be swapped out whenever its quantum expires, and if you've got higher priority threads, they will always run before those of lower priority -- even if they are spinning. I'm trying to debug weird hangs with mozilla. Once it hangs, I can't kill it except with SIGKILL, and then it seems to be stuck in symlook_obj(). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 19:24:20 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 2FB0B37B401; Mon, 28 Apr 2003 19:24:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AA3F43FBD; Mon, 28 Apr 2003 19:24: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 h3T2OGBg001061; Mon, 28 Apr 2003 22:24:16 -0400 (EDT) Received: from localhost (eischen@localhost)h3T2OG8w001057; Mon, 28 Apr 2003 22:24:16 -0400 (EDT) Date: Mon, 28 Apr 2003 22:24:16 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <006101c30df5$00438740$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread 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, 29 Apr 2003 02:24:20 -0000 On Tue, 29 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Tuesday, April 29, 2003 7:59 AM > Subject: Re: SMPing libpthread > > > > On Mon, 28 Apr 2003, David Xu wrote: > > > > > I have updated the libpthread SMP patch. > > > http://people.freebsd.org/~davidxu/libpthread_smp.diff > > > default is SMP enabled in the patch. the patch past all ACE tests, > > > also crew program was tested. > > > > Committed. I also made spinlock/spinunlock critical regions. > > Take a look at it and see if you think it'll work OK. All > > my tests pass with this. > > > > I found some DNS routines are using spinlock! so they > may be blocked in network transaction, it would lock out > our scheduler. I think we still need to rescure PS_SPINBLOCK > code from libc_r. No, let's replace them with mutexes. They shouldn't have crept in. Is this with the new NSS code that was just added? > > We still have a problem with mozilla. When I first got > > libkse working, mozilla worked for me but now it hangs > > upon startup (no window ever gets displayed). > > > Can you use gdb and press ctrl+c to see where it is dead loop? No, only SIGKILL works. See my other post about rtld :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 19:35:11 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E672837B401; Mon, 28 Apr 2003 19:35:11 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CE3243F93; Mon, 28 Apr 2003 19:35:11 -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 h3T2ZABg002841; Mon, 28 Apr 2003 22:35:10 -0400 (EDT) Received: from localhost (eischen@localhost)h3T2ZA3O002837; Mon, 28 Apr 2003 22:35:10 -0400 (EDT) Date: Mon, 28 Apr 2003 22:35:10 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: SMPing libpthread 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, 29 Apr 2003 02:35:12 -0000 On Mon, 28 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, David Xu wrote: > > > > > ----- Original Message ----- > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Tuesday, April 29, 2003 7:59 AM > > Subject: Re: SMPing libpthread > > > > > > > On Mon, 28 Apr 2003, David Xu wrote: > > > > > > > I have updated the libpthread SMP patch. > > > > http://people.freebsd.org/~davidxu/libpthread_smp.diff > > > > default is SMP enabled in the patch. the patch past all ACE tests, > > > > also crew program was tested. > > > > > > Committed. I also made spinlock/spinunlock critical regions. > > > Take a look at it and see if you think it'll work OK. All > > > my tests pass with this. > > > > > > > I found some DNS routines are using spinlock! so they > > may be blocked in network transaction, it would lock out > > our scheduler. I think we still need to rescure PS_SPINBLOCK > > code from libc_r. > > No, let's replace them with mutexes. They shouldn't have > crept in. Is this with the new NSS code that was just added? > > > > We still have a problem with mozilla. When I first got > > > libkse working, mozilla worked for me but now it hangs > > > upon startup (no window ever gets displayed). > > > > > Can you use gdb and press ctrl+c to see where it is dead loop? > > No, only SIGKILL works. See my other post about rtld :-) BTW David, you can debug mozilla with: $ /usr/X11R6/lib/mozilla-devel-gtk2/mozilla -g It's a shell script that will automatically start it up under the debugger. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 21:17:17 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0AD437B401; Mon, 28 Apr 2003 21:17:17 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B81D343FD7; Mon, 28 Apr 2003 21:17:16 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id A14182A7EA; Mon, 28 Apr 2003 21:17:16 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Date: Mon, 28 Apr 2003 21:17:16 -0700 From: Peter Wemm Message-Id: <20030429041716.A14182A7EA@canning.wemm.org> cc: jdp@freebsd.org cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 04:17:18 -0000 Daniel Eischen wrote: > So I was glancing at rltd-elf, specifically lockdflt.c. There > seems to be an assumption that sigprocmask() can be used to > protect a thread from being swapped out. Am I reading this > right? I dont think so.. i386/lockdflt.c is just a simple spinlock that happens to work with libc_r. > There are no such guarantees with libpthread. A thread > will be swapped out whenever its quantum expires, and if > you've got higher priority threads, they will always run > before those of lower priority -- even if they are spinning. If this is happening, it would not suprise me. lockdflt.c seems more aimed at things like the M3 runtime. I think the real solution is to provide a way for a thread library to hook in its own lock routines that use something that is thread aware. However, this is probably easier said than done. It looks like we had one (dllockinit(3)), but its now deprecated... revision 1.46 date: 2000/07/08 04:10:30; author: jdp; state: Exp; lines: +135 -115 Solve the dynamic linker's problems with multithreaded programs once and for all (I hope). Packages such as wine, JDK, and linuxthreads should no longer have any problems with re-entering the dynamic linker. ... Spinlocks are the only kinds of locks that work with all thread packages. But on uniprocessor systems they can be inefficient, because while a contender for the lock is spinning the holder of the lock cannot make any progress toward releasing it. To alleviate this disadvantage I have borrowed a trick from Sleepycat's Berkeley DB implementation. When spinning for a lock, the requester does a nanosleep() call for 1 usec. each time around the loop. This will generally yield the CPU to other threads, allowing the lock holder to finish its business and release the lock. I chose 1 usec. as the minimum sleep which would with reasonable certainty not be rounded down to 0. ... i386/lockdflt.c: revision 1.8 date: 2002/07/06 20:25:55; author: jdp; state: Exp; lines: +2 -9 Remove the nanosleep calls from the spin loops in the locking code. They provided little benefit (if any) and they caused some problems in OpenOffice, at least in post-KSE -current and perhaps in other environments too. The nanosleep calls prevented the profiling timer from advancing during the spinloops, thereby preventing the thread scheduler from ever pre-empting the spinning thread. .... ... This is a short-term fix for a larger problem. The use of spinlocking isn't guaranteed to work in all cases. For example, if the spinning thread has higher priority than all other threads, it may never be pre-empted, and the thread holding the lock may never progress far enough to release the lock. On the other hand, spinlocking is the only locking that can work with an arbitrary unknown threads package. I have some ideas for a much better fix in the longer term. It would eliminate all locking inside the dynamic linker by making it safe for symbol lookups and lazy binding to proceed in parallel with a call to dlopen or dlclose. This means that the only mutual exclusion needed would be to prevent multiple simultaneous calls to dlopen and/or dlclose. That mutual exclusion could be put into the native pthreads library. Applications using foreign threads packages would have to make their own arrangements to ensure that they did not have multiple threads in dlopen and/or dlclose -- a reasonable requirement in my opinion. ==== Basically he's describing the exact scenario you're concerned about. The last paragraph suggests a better way. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 22: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 4AFD437B401; Mon, 28 Apr 2003 22:28:35 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C9B43FDD; Mon, 28 Apr 2003 22:28:34 -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 h3T5SXBg028194; Tue, 29 Apr 2003 01:28:33 -0400 (EDT) Received: from localhost (eischen@localhost)h3T5SXHX028189; Tue, 29 Apr 2003 01:28:33 -0400 (EDT) Date: Tue, 29 Apr 2003 01:28:33 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030429041716.A14182A7EA@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jdp@freebsd.org cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 05:28:35 -0000 On Mon, 28 Apr 2003, Peter Wemm wrote: > Daniel Eischen wrote: > > So I was glancing at rltd-elf, specifically lockdflt.c. There > > seems to be an assumption that sigprocmask() can be used to > > protect a thread from being swapped out. Am I reading this > > right? > > I dont think so.. i386/lockdflt.c is just a simple spinlock that happens > to work with libc_r. > > > There are no such guarantees with libpthread. A thread > > will be swapped out whenever its quantum expires, and if > > you've got higher priority threads, they will always run > > before those of lower priority -- even if they are spinning. > > If this is happening, it would not suprise me. lockdflt.c seems more aimed > at things like the M3 runtime. > > I think the real solution is to provide a way for a thread library to hook > in its own lock routines that use something that is thread aware. However, > this is probably easier said than done. Well, libc can do it by checking __isthreaded and then using mutexes. Libraries such as libgcc can also handle it by making weak references (not definitions) to pthread_foo and then using them when they are not null. I don't know if this works for rtld though. > Basically he's describing the exact scenario you're concerned about. The > last paragraph suggests a better way. John, any details about what you were thinking here? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 28 23:08: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 90E8B37B401; Mon, 28 Apr 2003 23:08:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AC143F75; Mon, 28 Apr 2003 23:08: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 h3T68UUp026122; Mon, 28 Apr 2003 23:08:31 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <00a201c30e16$08f291d0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Tue, 29 Apr 2003 14:10:28 +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: libpthread sigwait patch 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, 29 Apr 2003 06:08:32 -0000 Now, I am start to looking some signal code in libpthread, here is my first signal patch to allow MySQL server 4.0.10=20 run on my machine happily. http://people.freebsd.org/~davidxu/thr_sigwait.c.diff David Xu From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 05:08:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A6B137B401; Tue, 29 Apr 2003 05:08:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F50D43F75; Tue, 29 Apr 2003 05:08:31 -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 h3TC8UBg022968; Tue, 29 Apr 2003 08:08:30 -0400 (EDT) Received: from localhost (eischen@localhost)h3TC8UKg022963; Tue, 29 Apr 2003 08:08:30 -0400 (EDT) Date: Tue, 29 Apr 2003 08:08:30 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <00a201c30e16$08f291d0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: libpthread sigwait patch 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, 29 Apr 2003 12:08:36 -0000 On Tue, 29 Apr 2003, David Xu wrote: > Now, I am start to looking some signal code in libpthread, > here is my first signal patch to allow MySQL server 4.0.10 > run on my machine happily. Yeah, that' what I was looking at (signal code). We need a better way of setting up signals on running threads. Right now they're just added to the pending set, but thr_sched_switch() or the scheduler need to add them to the frame. > http://people.freebsd.org/~davidxu/thr_sigwait.c.diff I'll take a look. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 05:29: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 9777A37B401; Tue, 29 Apr 2003 05:29:35 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8274643F3F; Tue, 29 Apr 2003 05:29:34 -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 h3TCTXUp021502; Tue, 29 Apr 2003 05:29:33 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <000f01c30e4b$968f36d0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: Date: Tue, 29 Apr 2003 20:33:49 +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 sigwait patch 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: Tue, 29 Apr 2003 12:29:35 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Tuesday, April 29, 2003 8:08 PM Subject: Re: libpthread sigwait patch > On Tue, 29 Apr 2003, David Xu wrote: >=20 > > Now, I am start to looking some signal code in libpthread, > > here is my first signal patch to allow MySQL server 4.0.10=20 > > run on my machine happily. >=20 > Yeah, that' what I was looking at (signal code). We need > a better way of setting up signals on running threads. > Right now they're just added to the pending set, but > thr_sched_switch() or the scheduler need to add them > to the frame. >=20 Yes, I would like to let scheduler install a signal frame,=20 in scheduler, it might not need to call THR_GETCONTEXT, just use already existing context, and we might have chance to=20 direct push signal from kernel upcall to thread, I think pthread_sigmask can do a context switch to let scheduler install a signal frame for it, these are my random ideas... probably you already have some code for these ? :-) > > http://people.freebsd.org/~davidxu/thr_sigwait.c.diff >=20 > I'll take a look. >=20 > --=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 Tue Apr 29 06:10:40 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D05037B401; Tue, 29 Apr 2003 06:10:40 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E95B43F75; Tue, 29 Apr 2003 06:10:39 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3TDAb6U075179; Tue, 29 Apr 2003 16:10:37 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TDAadU075176; Tue, 29 Apr 2003 16:10:37 +0300 (EEST) Date: Tue, 29 Apr 2003 16:10:36 +0300 (EEST) From: Narvi To: Peter Wemm In-Reply-To: <20030429041716.A14182A7EA@canning.wemm.org> Message-ID: <20030429145307.L40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 13:10:40 -0000 [snip] > ... > This is a short-term fix for a larger problem. The use of spinlocking > isn't guaranteed to work in all cases. For example, if the spinning > thread has higher priority than all other threads, it may never be > pre-empted, and the thread holding the lock may never progress far > enough to release the lock. On the other hand, spinlocking is the > only locking that can work with an arbitrary unknown threads package. > > I have some ideas for a much better fix in the longer term. It > would eliminate all locking inside the dynamic linker by making it > safe for symbol lookups and lazy binding to proceed in parallel > with a call to dlopen or dlclose. This means that the only mutual > exclusion needed would be to prevent multiple simultaneous calls > to dlopen and/or dlclose. That mutual exclusion could be put into > the native pthreads library. Applications using foreign threads > packages would have to make their own arrangements to ensure that > they did not have multiple threads in dlopen and/or dlclose -- a > reasonable requirement in my opinion. > ==== > > Basically he's describing the exact scenario you're concerned about. The > last paragraph suggests a better way. > You will then need to make sure something sensible (and not a deadlock) happens if fork() gets called at a time when dlopen() / dlclose() is running in another thread. > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 08:20: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 BC02037B401 for ; Tue, 29 Apr 2003 08:20:08 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD92A43FA3 for ; Tue, 29 Apr 2003 08:20: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 h3TFK6Bg022939; Tue, 29 Apr 2003 11:20:06 -0400 (EDT) Received: from localhost (eischen@localhost)h3TFK5N6022934; Tue, 29 Apr 2003 11:20:06 -0400 (EDT) Date: Tue, 29 Apr 2003 11:20:05 -0400 (EDT) From: Daniel Eischen To: Narvi In-Reply-To: <20030429145307.L40030-100000@haldjas.folklore.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 15:20:09 -0000 On Tue, 29 Apr 2003, Narvi wrote: > [snip] > > > ... > > This is a short-term fix for a larger problem. The use of spinlocking > > isn't guaranteed to work in all cases. For example, if the spinning > > thread has higher priority than all other threads, it may never be > > pre-empted, and the thread holding the lock may never progress far > > enough to release the lock. On the other hand, spinlocking is the > > only locking that can work with an arbitrary unknown threads package. > > > > I have some ideas for a much better fix in the longer term. It > > would eliminate all locking inside the dynamic linker by making it > > safe for symbol lookups and lazy binding to proceed in parallel > > with a call to dlopen or dlclose. This means that the only mutual > > exclusion needed would be to prevent multiple simultaneous calls > > to dlopen and/or dlclose. That mutual exclusion could be put into > > the native pthreads library. Applications using foreign threads > > packages would have to make their own arrangements to ensure that > > they did not have multiple threads in dlopen and/or dlclose -- a > > reasonable requirement in my opinion. > > ==== > > > > Basically he's describing the exact scenario you're concerned about. The > > last paragraph suggests a better way. > > > > You will then need to make sure something sensible (and not a deadlock) > happens if fork() gets called at a time when dlopen() / dlclose() is > running in another thread. How is this any different than spinlocks or mutexes used in libc (malloc, free, etc)? Yes, this is true, but no threads library that we have currently tracks internal locks so they can be reinitialized after a fork. It is possible that a fork() will leave things in the locked state. But even if they were locked, you'd only see a problem if the forked program again became threaded. We do need to fix this, and it is one of the things on my TODO list. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 09:41: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 58B6137B401 for ; Tue, 29 Apr 2003 09:41:18 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23EE043F3F for ; Tue, 29 Apr 2003 09:41:17 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h3TGfFds097783; Tue, 29 Apr 2003 09:41:16 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 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: Tue, 29 Apr 2003 09:41:15 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Daniel Eischen cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 16:41:18 -0000 Hi Daniel, > So I was glancing at rltd-elf, specifically lockdflt.c. There > seems to be an assumption that sigprocmask() can be used to > protect a thread from being swapped out. Am I reading this > right? > > There are no such guarantees with libpthread. A thread > will be swapped out whenever its quantum expires, and if > you've got higher priority threads, they will always run > before those of lower priority -- even if they are spinning. > > I'm trying to debug weird hangs with mozilla. Once it > hangs, I can't kill it except with SIGKILL, and then > it seems to be stuck in symlook_obj(). I'd strongly recommend that you read the complete log messages for "src/libexec/rtld-elf/i386/lockdflt.c" in chronological order to find out what all has been tried and why none of it worked. It's a pretty sad history. :-( I now believe that the most workable solution is to rejigger the data structures inside the dynamic linker such that locking is no longer needed for normal operations (loading shared libraries, resolving symbol references, performing lazy binding, etc.). I think it's possible to change things so that the only time locking is needed is to prevent multiple invocations of dlopen, dlclose, etc., from interfering with each other. Trying to tie into the pthread locking functions didn't work, because (1) it is too hard to prevent lazy binding from occuring as a result of calling the locking functions themselves, and (2) there are lots of applications out there that use their own threads packages instead of the system's. John From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 11:03: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 1DE8037B401 for ; Tue, 29 Apr 2003 11:03:03 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7C7A43F85 for ; Tue, 29 Apr 2003 11:02:59 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3TI2w6U078341; Tue, 29 Apr 2003 21:02:58 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TI2wLN078338; Tue, 29 Apr 2003 21:02:58 +0300 (EEST) Date: Tue, 29 Apr 2003 21:02:58 +0300 (EEST) From: Narvi To: Daniel Eischen In-Reply-To: Message-ID: <20030429202837.L40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 18:03:03 -0000 On Tue, 29 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, Narvi wrote: > > [snip] > > > > > ... > > > This is a short-term fix for a larger problem. The use of spinlocking > > > isn't guaranteed to work in all cases. For example, if the spinning > > > thread has higher priority than all other threads, it may never be > > > pre-empted, and the thread holding the lock may never progress far > > > enough to release the lock. On the other hand, spinlocking is the > > > only locking that can work with an arbitrary unknown threads package. > > > > > > I have some ideas for a much better fix in the longer term. It > > > would eliminate all locking inside the dynamic linker by making it > > > safe for symbol lookups and lazy binding to proceed in parallel > > > with a call to dlopen or dlclose. This means that the only mutual > > > exclusion needed would be to prevent multiple simultaneous calls > > > to dlopen and/or dlclose. That mutual exclusion could be put into > > > the native pthreads library. Applications using foreign threads > > > packages would have to make their own arrangements to ensure that > > > they did not have multiple threads in dlopen and/or dlclose -- a > > > reasonable requirement in my opinion. > > > ==== > > > > > > Basically he's describing the exact scenario you're concerned about. The > > > last paragraph suggests a better way. > > > > > > > You will then need to make sure something sensible (and not a deadlock) > > happens if fork() gets called at a time when dlopen() / dlclose() is > > running in another thread. > > How is this any different than spinlocks or mutexes used > in libc (malloc, free, etc)? > its not, really. locks in the dynamic linker usualy just make things a bit more interesting than locks elsewhere. > Yes, this is true, but no threads library that we have currently > tracks internal locks so they can be reinitialized after a fork. > It is possible that a fork() will leave things in the locked > state. But even if they were locked, you'd only see a problem > if the forked program again became threaded. > No, you would see the problem as soon as you tried to use a function that used a locked structure, depending on how the dynamic linker did thinks this might include any fiunction, including exec* - threads + forking gives you really fascinating problems. How do you know that say malloc state was consistent at the moment you forked? You really need per-subsystem cleanups so that you won't occasionaly fail miserably. Its not really the threads lib that can / should track locks, unless it comes with its own copy of the subsystems. > We do need to fix this, and it is one of the things on my > TODO list. > > -- > Dan Eischen > From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 11:22:11 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EDE437B401 for ; Tue, 29 Apr 2003 11:22:11 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE4243F85 for ; Tue, 29 Apr 2003 11:22:10 -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 h3TIM9Bg023530; Tue, 29 Apr 2003 14:22:09 -0400 (EDT) Received: from localhost (eischen@localhost)h3TIM9eg023527; Tue, 29 Apr 2003 14:22:09 -0400 (EDT) Date: Tue, 29 Apr 2003 14:22:09 -0400 (EDT) From: Daniel Eischen To: Narvi In-Reply-To: <20030429202837.L40030-100000@haldjas.folklore.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 18:22:11 -0000 On Tue, 29 Apr 2003, Narvi wrote: > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > > On Tue, 29 Apr 2003, Narvi wrote: > > > [snip] > > > > > > > ... > > > > This is a short-term fix for a larger problem. The use of spinlocking > > > > isn't guaranteed to work in all cases. For example, if the spinning > > > > thread has higher priority than all other threads, it may never be > > > > pre-empted, and the thread holding the lock may never progress far > > > > enough to release the lock. On the other hand, spinlocking is the > > > > only locking that can work with an arbitrary unknown threads package. > > > > > > > > I have some ideas for a much better fix in the longer term. It > > > > would eliminate all locking inside the dynamic linker by making it > > > > safe for symbol lookups and lazy binding to proceed in parallel > > > > with a call to dlopen or dlclose. This means that the only mutual > > > > exclusion needed would be to prevent multiple simultaneous calls > > > > to dlopen and/or dlclose. That mutual exclusion could be put into > > > > the native pthreads library. Applications using foreign threads > > > > packages would have to make their own arrangements to ensure that > > > > they did not have multiple threads in dlopen and/or dlclose -- a > > > > reasonable requirement in my opinion. > > > > ==== > > > > > > > > Basically he's describing the exact scenario you're concerned about. The > > > > last paragraph suggests a better way. > > > > > > > > > > You will then need to make sure something sensible (and not a deadlock) > > > happens if fork() gets called at a time when dlopen() / dlclose() is > > > running in another thread. > > > > How is this any different than spinlocks or mutexes used > > in libc (malloc, free, etc)? > > > > its not, really. locks in the dynamic linker usualy just make things a bit > more interesting than locks elsewhere. > > > Yes, this is true, but no threads library that we have currently > > tracks internal locks so they can be reinitialized after a fork. > > It is possible that a fork() will leave things in the locked > > state. But even if they were locked, you'd only see a problem > > if the forked program again became threaded. > > > > No, you would see the problem as soon as you tried to use a function that > used a locked structure, depending on how the dynamic linker did thinks > this might include any fiunction, including exec* - threads + forking > gives you really fascinating problems. How do you know that say malloc > state was consistent at the moment you forked? You really need > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > not really the threads lib that can / should track locks, unless it comes > with its own copy of the subsystems. Locks are not used unless __isthreaded is true. After a fork(), __isthreaded gets set back to 0 so locks are not used. Assuming rtld were changed to use the same types of locks that libc uses (which jdp suggests isn't the best way), you would take the same approach. So no matter what state the locks were in, as long as you didn't become threaded again, you wouldn't attempt to use the lock. Usually fork()s from threaded applications are not to launch another threaded instance of the application. Even so, we still would like this to work. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 11:53:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD12F37B404; Tue, 29 Apr 2003 11:53:36 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95B543FD7; Tue, 29 Apr 2003 11:53:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AaEI-0005NN-00; Tue, 29 Apr 2003 11:53:27 -0700 Message-ID: <3EAEC9D2.AE47CC0A@mindspring.com> Date: Tue, 29 Apr 2003 11:52:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030429145307.L40030-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43096268d63a3255db8e68c054dc5bf57a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 18:53:37 -0000 Narvi wrote: > Peter Wemm wrote: > > Basically he's describing the exact scenario you're concerned about. The > > last paragraph suggests a better way. > > You will then need to make sure something sensible (and not a deadlock) > happens if fork() gets called at a time when dlopen() / dlclose() is > running in another thread. I think this is a non-sequitur; what's "sensible" in that case? Should the address space of the fork()'ed process contain the dlopen()'ed object, or not? It seems to me that this situation is a coding error on the part of the person who did not manually serialize access through a pthread mutex, so that the address space was controlled over the fork(), and the resulting process ended up with the state of its address space known to the programmer. I think it's OK to fail pretty spectacularly if a programmer is silly enough to cause this situation to occur in the first place; the idea that the protection against this type of coding error should be intrinsic to the library ignores the order-of-operation issue, which can only be resolved by the computer reading the programmers mind to determine the intent of the programmer. This reminds me of the kooks who pop up every once in a while and demand that libc functions not segfault when passed NULL pointers, and that all arguments be checked by the libc functions before they are used... an OS with training wheels, so to speak. -- Terry From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 12:14:29 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 794C537B401 for ; Tue, 29 Apr 2003 12:14:29 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A897843FAF for ; Tue, 29 Apr 2003 12:14:28 -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 h3TJERBg002680; Tue, 29 Apr 2003 15:14:27 -0400 (EDT) Received: from localhost (eischen@localhost)h3TJERhP002677; Tue, 29 Apr 2003 15:14:27 -0400 (EDT) Date: Tue, 29 Apr 2003 15:14:27 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EAEC9D2.AE47CC0A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 19:14:29 -0000 On Tue, 29 Apr 2003, Terry Lambert wrote: > Narvi wrote: > > Peter Wemm wrote: > > > Basically he's describing the exact scenario you're concerned about. The > > > last paragraph suggests a better way. > > > > You will then need to make sure something sensible (and not a deadlock) > > happens if fork() gets called at a time when dlopen() / dlclose() is > > running in another thread. > > I think this is a non-sequitur; what's "sensible" in that case? > Should the address space of the fork()'ed process contain the > dlopen()'ed object, or not? > > It seems to me that this situation is a coding error on the part > of the person who did not manually serialize access through a > pthread mutex, so that the address space was controlled over the > fork(), and the resulting process ended up with the state of its > address space known to the programmer. Indeed. POSIX also has this to say about fork(): A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not asynch-signal-safe, the behavior is undefined. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 12:29: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 CB4EA37B401 for ; Tue, 29 Apr 2003 12:29: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 4424243F3F for ; Tue, 29 Apr 2003 12:29:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Aan3-0006Ah-00; Tue, 29 Apr 2003 12:29:22 -0700 Message-ID: <3EAED240.9A2C0534@mindspring.com> Date: Tue, 29 Apr 2003 12:28:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030429202837.L40030-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48f4d056159cc70ff3bf6ed99055ba00f3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 19:29:32 -0000 Narvi wrote: > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > Yes, this is true, but no threads library that we have currently > > tracks internal locks so they can be reinitialized after a fork. > > It is possible that a fork() will leave things in the locked > > state. But even if they were locked, you'd only see a problem > > if the forked program again became threaded. > > No, you would see the problem as soon as you tried to use a function that > used a locked structure, depending on how the dynamic linker did thinks > this might include any fiunction, including exec* - threads + forking > gives you really fascinating problems. How do you know that say malloc > state was consistent at the moment you forked? You really need > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > not really the threads lib that can / should track locks, unless it comes > with its own copy of the subsystems. Exactly. It's a programming error. You don't know if they wanted the dlopen()'ed object in scope in the child process after the fork, or not, so if you have a dlopen()/fork() race, you can never know if it will get added (or removed, if we include dlclose() races) before or after the actual fork() has taken place. It's bogus for the programmer to use these types of interfaces without providing their own serialization so that they know for certain what the state of the mapped object is, after the fork(). -- Terry From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 12:42:30 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C699037B401 for ; Tue, 29 Apr 2003 12:42:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A49E43F75 for ; Tue, 29 Apr 2003 12:42:30 -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 h3TJgRBg007736; Tue, 29 Apr 2003 15:42:27 -0400 (EDT) Received: from localhost (eischen@localhost)h3TJgQ1p007733; Tue, 29 Apr 2003 15:42:26 -0400 (EDT) Date: Tue, 29 Apr 2003 15:42:26 -0400 (EDT) From: Daniel Eischen To: Narvi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 19:42:31 -0000 On Tue, 29 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, Narvi wrote: > > > > No, you would see the problem as soon as you tried to use a function that > > used a locked structure, depending on how the dynamic linker did thinks > > this might include any fiunction, including exec* - threads + forking > > gives you really fascinating problems. How do you know that say malloc > > state was consistent at the moment you forked? You really need > > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > > not really the threads lib that can / should track locks, unless it comes > > with its own copy of the subsystems. In regards to inconsistent data (and not the state of the locks)... You could have use an atfork() handler to reinitialize any inconsistent data. POSIX already defines pthread_atfork(), and the kernel has at_fork(9) for kernel modules. Perhaps pthread_atfork() could be utilized by libc, being careful to detect the potential for threads first. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 14:59: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 4F07037B401 for ; Tue, 29 Apr 2003 14:59:18 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD5F43F75 for ; Tue, 29 Apr 2003 14:59:17 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3TLxF6U080344; Wed, 30 Apr 2003 00:59:16 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TLxFjB080341; Wed, 30 Apr 2003 00:59:15 +0300 (EEST) Date: Wed, 30 Apr 2003 00:59:15 +0300 (EEST) From: Narvi To: Daniel Eischen In-Reply-To: Message-ID: <20030429234505.X40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 21:59:18 -0000 On Tue, 29 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > > On Tue, 29 Apr 2003, Narvi wrote: > > > > > > No, you would see the problem as soon as you tried to use a function that > > > used a locked structure, depending on how the dynamic linker did thinks > > > this might include any fiunction, including exec* - threads + forking > > > gives you really fascinating problems. How do you know that say malloc > > > state was consistent at the moment you forked? You really need > > > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > > > not really the threads lib that can / should track locks, unless it comes > > > with its own copy of the subsystems. > > In regards to inconsistent data (and not the state of the locks)... > > You could have use an atfork() handler to reinitialize any > inconsistent data. POSIX already defines pthread_atfork(), > and the kernel has at_fork(9) for kernel modules. Perhaps > pthread_atfork() could be utilized by libc, being careful > to detect the potential for threads first. > Well, i think we should gurantee something about the sanity of libc internals to the forked process. I think it would be more efficent to use a specific cleanup function that fork() implicitly knows about instead of a number of actual calls to pthread_atfork. You could probaby set things up so with rtld that the cleanups happen lazily so that there is no overhead for immediate / near-immediate exec with no acess to functions that would need the cleanup, but I don't think its an immediate concern. > -- > Dan Eischen > From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 15:47: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 E186137B401; Tue, 29 Apr 2003 15:47:18 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A77543F75; Tue, 29 Apr 2003 15:47:16 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3TMlF6U080680; Wed, 30 Apr 2003 01:47:15 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TMlEUg080676; Wed, 30 Apr 2003 01:47:14 +0300 (EEST) Date: Wed, 30 Apr 2003 01:47:14 +0300 (EEST) From: Narvi To: Terry Lambert In-Reply-To: <3EAEC9D2.AE47CC0A@mindspring.com> Message-ID: <20030429221724.S40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 22:47:19 -0000 On Tue, 29 Apr 2003, Terry Lambert wrote: > Narvi wrote: > > Peter Wemm wrote: > > > Basically he's describing the exact scenario you're concerned about. The > > > last paragraph suggests a better way. > > > > You will then need to make sure something sensible (and not a deadlock) > > happens if fork() gets called at a time when dlopen() / dlclose() is > > running in another thread. > > I think this is a non-sequitur; what's "sensible" in that case? > Should the address space of the fork()'ed process contain the > dlopen()'ed object, or not? > It should either contain the object and the symbols or neither, not a in-between situation. And it shouldn't cause a deadlock just because you called a function that needs re-entering into the rtld or crashing because you called dlsym and got handed a pointer pointing to nowhere. > It seems to me that this situation is a coding error on the part > of the person who did not manually serialize access through a > pthread mutex, so that the address space was controlled over the > fork(), and the resulting process ended up with the state of its > address space known to the programmer. > And exactly why would they have to assume that there is a problem? Especially as a library function can call a dlopen() without their knowledge (or really for that matter, call fork without their knowledge), so there isn't anything they can do either. If it is allowable to use functions from libraries you don't have source to in two different threads (and I can't imagine there being a serious restriction not to) there is nothing that can be done by the programmer, except possibly avoiding freebsd. > I think it's OK to fail pretty spectacularly if a programmer is > silly enough to cause this situation to occur in the first place; > the idea that the protection against this type of coding error > should be intrinsic to the library ignores the order-of-operation > issue, which can only be resolved by the computer reading the > programmers mind to determine the intent of the programmer. > No mind reading is necessary - you have the choice of either delaying fork() until the dlopen() completes or reaches some safe stage from which cleanup is possible or you can schedule a fork() time cleanup that can undo any state. Nothing in dlopen() specs claims it is not fork() or threading safe. Non-thread safety would still give you at most one concurrent copy and not p[rotection from fork(). > This reminds me of the kooks who pop up every once in a while and > demand that libc functions not segfault when passed NULL pointers, > and that all arguments be checked by the libc functions before > they are used... an OS with training wheels, so to speak. > Thsi is not even close to similar situation. > -- Terry > From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 21:59: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 1D01E37B404 for ; Tue, 29 Apr 2003 21:59:27 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C6E43FDF for ; Tue, 29 Apr 2003 21:59:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 40FD82A7EA; Tue, 29 Apr 2003 21:59:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Narvi In-Reply-To: <20030429234505.X40030-100000@haldjas.folklore.ee> Date: Tue, 29 Apr 2003 21:59:26 -0700 From: Peter Wemm Message-Id: <20030430045926.40FD82A7EA@canning.wemm.org> cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 04:59:27 -0000 Narvi wrote: > > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > > > > On Tue, 29 Apr 2003, Narvi wrote: > > > > > > > > No, you would see the problem as soon as you tried to use a function th at > > > > used a locked structure, depending on how the dynamic linker did thinks > > > > this might include any fiunction, including exec* - threads + forking > > > > gives you really fascinating problems. How do you know that say malloc > > > > state was consistent at the moment you forked? You really need > > > > per-subsystem cleanups so that you won't occasionaly fail miserably. It s > > > > not really the threads lib that can / should track locks, unless it com es > > > > with its own copy of the subsystems. > > > > In regards to inconsistent data (and not the state of the locks)... > > > > You could have use an atfork() handler to reinitialize any > > inconsistent data. POSIX already defines pthread_atfork(), > > and the kernel has at_fork(9) for kernel modules. Perhaps > > pthread_atfork() could be utilized by libc, being careful > > to detect the potential for threads first. > > > > Well, i think we should gurantee something about the sanity of libc > internals to the forked process. This is getting a bit sidetracked here. Remember the issue at hand is how to protect the ld-elf.so.1 internals in a pthread context. Not how to recover from a fork(). One way I've seen is to have libc and the respective pthreads libraries provide the public access to things like dlopen() etc. That way, the threads package of your choice does its own serialization of the entry points into the dynamic linker guts/internals. As John Polstra said earlier, he has some thoughts about how to make the actual lazy symbol lookup be thread-safe. If I recall correctly, our old a.out based shared lib implementation did it precicely this way. dlopen() was a function in libc, that called through a vector into the guts of ld.so.1. The dynamic linker itself never provided direct call access to this stuff. Some systems put these public functions in a seperate library, -ldl. The ELF implemetation that we use does, and doesn't give the threads library a chance to wrap them. (And no, this is not an invitation for getting sidetracked on making ld-elf.so.1 into libdl.so.1 as a service library, etc etc) How would things go if we renamed the ld-elf.so functions to __rtld_dlopen() etc and then had libc provide a weak dlopen() function that redirected to __rtld_dlopen(), and give libpthread a chance to provide a replacement? And of course, deal with making the runtime symbol resolution as John suggested in the commit logs. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 22:23: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 B6C5F37B401; Tue, 29 Apr 2003 22:23:48 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1458F43F85; Tue, 29 Apr 2003 22:23:48 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Ak4G-0004e2-00; Tue, 29 Apr 2003 22:23:45 -0700 Message-ID: <3EAF5D88.B9771607@mindspring.com> Date: Tue, 29 Apr 2003 22:22:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030429221724.S40030-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a439aca234a5374811173dddced9bf4fc0548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 05:23:49 -0000 Narvi wrote: > On Tue, 29 Apr 2003, Terry Lambert wrote: > > I think this is a non-sequitur; what's "sensible" in that case? > > Should the address space of the fork()'ed process contain the > > dlopen()'ed object, or not? > > It should either contain the object and the symbols or neither, not a > in-between situation. And it shouldn't cause a deadlock just because you > called a function that needs re-entering into the rtld or crashing because > you called dlsym and got handed a pointer pointing to nowhere. That's exactly how it works, if you serialize access to thread unsafe functions, as documented by POSIX, so that the "behaviour is undefined" never occurs. > > It seems to me that this situation is a coding error on the part > > of the person who did not manually serialize access through a > > pthread mutex, so that the address space was controlled over the > > fork(), and the resulting process ended up with the state of its > > address space known to the programmer. > > And exactly why would they have to assume that there is a problem? Because the standards documents say that the behaviour is undefined? > Especially as a library function can call a dlopen() without their > knowledge (or really for that matter, call fork without their knowledge), > so there isn't anything they can do either. If it is allowable to use > functions from libraries you don't have source to in two different threads > (and I can't imagine there being a serious restriction not to) there is > nothing that can be done by the programmer, except possibly avoiding > freebsd. If it's the threaded libc, it can know whether it needs to serialize, because it's the source code calling the dangerous interface. > > I think it's OK to fail pretty spectacularly if a programmer is > > silly enough to cause this situation to occur in the first place; > > the idea that the protection against this type of coding error > > should be intrinsic to the library ignores the order-of-operation > > issue, which can only be resolved by the computer reading the > > programmers mind to determine the intent of the programmer. > > No mind reading is necessary - you have the choice of either delaying > fork() until the dlopen() completes or reaches some safe stage from which > cleanup is possible or you can schedule a fork() time cleanup that can > undo any state. Nothing in dlopen() specs claims it is not fork() or > threading safe. Non-thread safety would still give you at most one > concurrent copy and not p[rotection from fork(). You need to read the Corrigenda and the functional overview in Chapter 12 of the Single UNIX Specification (POSIX, X/Open). It says in dlerror(), and I quote: Note that this interface is not thread safe, since the string may reside in a static area which is overwritten whenever an error occurs. Application code should not write to this buffer. Programs wishing to preserve an error message should make their own copies of that message. Depending on the application environment with respect to asynchronous execution events, such as signals or other asynchronous computation sharing the address space, portable applications should use a critical section to retrieve the error pointer and buffer. In fact, it's pretty clear that since this error is potentially set in place on each invocation of a dl*() function, that this critical sectioning applies to callers of the function itself. It's pretty clear that the Aspen Group screwed the pooch on the dlopen() set of commands; specifically, it's pretty clear that they did not expect them to be used except in setup or teardown, and not used subsequently under active operation. FWIW, there's more in the "Go Solo 2" book, including that these are expected to be system interfaces, which means that there is also an expectation of serialization by the kernel, and that a descriptor reference is set for mmap() (which has the same set of problems), but which is an implementation detail not under technical control of the standard (i.e. it doesn't work that way in FreeBSD, per se, or any BSD-derived system). -- Terry From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 22:43:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190AD37B401 for ; Tue, 29 Apr 2003 22:43:25 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8A643F75 for ; Tue, 29 Apr 2003 22:43:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AkNB-0004fR-00; Tue, 29 Apr 2003 22:43:18 -0700 Message-ID: <3EAF621C.E59B1AD5@mindspring.com> Date: Tue, 29 Apr 2003 22:41:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030430045926.40FD82A7EA@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d9e273c74a1d9f4c9c273c18587415ed548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 05:43:25 -0000 Peter Wemm wrote: > Narvi wrote: > > Well, i think we should gurantee something about the sanity of libc > > internals to the forked process. > > This is getting a bit sidetracked here. Remember the issue at hand > is how to protect the ld-elf.so.1 internals in a pthread context. Not > how to recover from a fork(). > > One way I've seen is to have libc and the respective pthreads libraries > provide the public access to things like dlopen() etc. That way, the > threads package of your choice does its own serialization of the entry > points into the dynamic linker guts/internals. As John Polstra said > earlier, he has some thoughts about how to make the actual lazy symbol > lookup be thread-safe. This is actually hard to do, given the way that the ld.so gets mapped in and referenced by the crt0 code. I don't actually know if it would even be possible, even with two levels of weak symbol indirection. One really hard problem is a statically linked threaded program still trying to override the symbols with weak references to things that aren't there (hence the two levels of indirection). One of the "magic" things that's assumed in the SUS, and by the X/Open and POSIX codification of SVR4 behaviour as "correct UNIX" (be honest: that's what those standards are) is that there is a "reserved" low end memory range, well below the link address of user programs. This is actually used for the *kernel* to map the ld.so into the process address space on the processes behalf; it's why there's a dlopen() available in static binaries on SVR4. This change is pretty radical, from a BSD perspective, not the least of which because of the base address space having to be prereserved, but it would certainly solve the problem. > If I recall correctly, our old a.out based shared lib implementation did it > precicely this way. dlopen() was a function in libc, that called through > a vector into the guts of ld.so.1. The dynamic linker itself never provided > direct call access to this stuff. Some systems put these public functions > in a seperate library, -ldl. The ELF implemetation that we use does, and > doesn't give the threads library a chance to wrap them. Yes. Now it's referenced through the crt0 stuff; this happened when we did a compiler and tools import, and changed to "the GCC way" of doing things, in the great ELF switchover. In many ways, I miss a.out: ELF has failed to have its capabilities used to a reasonable extent (pageable code and data sections in the kernel, etc.). 8-(. > (And no, this is not an invitation for getting sidetracked on making > ld-elf.so.1 into libdl.so.1 as a service library, etc etc) > > How would things go if we renamed the ld-elf.so functions to __rtld_dlopen() > etc and then had libc provide a weak dlopen() function that redirected to > __rtld_dlopen(), and give libpthread a chance to provide a replacement? > And of course, deal with making the runtime symbol resolution as John > suggested in the commit logs. You would need two weak references, one of which was a weak reference to the "real" reference (the "fake" functions in the non-dynamic case), and the other which was a weak reference to the weak reference, to let the libc_r (or whatever) override the libc reference. Last time I checked my linker-foo, there was a problem with doing this in GCC (it caused a library link error in Archie's work on the Kaffe JNI code, while using dlopen; the only fix was to statically link an intermediate library that had the middle symbols in it; maybe this could be jammed into the crt0 code). -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 08:27: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 776AD37B49F; Wed, 30 Apr 2003 08:27:34 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 933BB43F3F; Wed, 30 Apr 2003 08:27:33 -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 h3UFRWBg007308; Wed, 30 Apr 2003 11:27:32 -0400 (EDT) Received: from localhost (eischen@localhost)h3UFRWcF007305; Wed, 30 Apr 2003 11:27:32 -0400 (EDT) Date: Wed, 30 Apr 2003 11:27:32 -0400 (EDT) From: Daniel Eischen To: threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: cvs commit: src/lib/libpthread/arch/i386/include pthread_md.h src/lib/libpthread/thread thr_create.c thr_init.c thr_kern.c thr_private.h (fwd) 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, 30 Apr 2003 15:27:34 -0000 This should fix the problem of knode crashing. Perhaps other problems too. ---------- Forwarded message ---------- Date: Wed, 30 Apr 2003 08:05:17 -0700 (PDT) From: Daniel Eischen To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libpthread/arch/i386/include pthread_md.h src/lib/libpthread/thread thr_create.c thr_init.c thr_kern.c thr_private.h deischen 2003/04/30 08:05:17 PDT FreeBSD src repository Modified files: lib/libpthread/arch/i386/include pthread_md.h lib/libpthread/thread thr_create.c thr_init.c thr_kern.c thr_private.h Log: Move the mailbox to the beginning of the thread and align the thread so that the context (SSE FPU state) is also aligned. Revision Changes Path 1.3 +3 -0 src/lib/libpthread/arch/i386/include/pthread_md.h 1.43 +3 -0 src/lib/libpthread/thread/thr_create.c 1.51 +3 -0 src/lib/libpthread/thread/thr_init.c 1.62 +9 -3 src/lib/libpthread/thread/thr_kern.c 1.85 +6 -4 src/lib/libpthread/thread/thr_private.h From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 08:51: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 A56C537B401 for ; Wed, 30 Apr 2003 08:51:26 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DF143F3F for ; Wed, 30 Apr 2003 08:51:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 377792A8A8; Wed, 30 Apr 2003 08:51:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert In-Reply-To: <3EAF621C.E59B1AD5@mindspring.com> Date: Wed, 30 Apr 2003 08:51:26 -0700 From: Peter Wemm Message-Id: <20030430155126.377792A8A8@canning.wemm.org> cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 15:51:26 -0000 Terry Lambert wrote: > This is actually used for the *kernel* to map the > ld.so into the process address space on the processes behalf; it's > why there's a dlopen() available in static binaries on SVR4. Not on the SVR4 (pre-solaris) that I used. The linker didn't generate the data in static binaries that ld.so needed at runtime. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 10:48:15 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 7BF7E37B401 for ; Wed, 30 Apr 2003 10:48:15 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFA3443F3F for ; Wed, 30 Apr 2003 10:48:14 -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 h3UHmDBg000063; Wed, 30 Apr 2003 13:48:13 -0400 (EDT) Received: from localhost (eischen@localhost)h3UHmD2s000054; Wed, 30 Apr 2003 13:48:13 -0400 (EDT) Date: Wed, 30 Apr 2003 13:48:13 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030430045926.40FD82A7EA@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 17:48:15 -0000 On Tue, 29 Apr 2003, Peter Wemm wrote: > One way I've seen is to have libc and the respective pthreads libraries > provide the public access to things like dlopen() etc. That way, the > threads package of your choice does its own serialization of the entry > points into the dynamic linker guts/internals. As John Polstra said > earlier, he has some thoughts about how to make the actual lazy symbol > lookup be thread-safe. I think this would work. It could even be done in our libc, just as malloc, stdio, and friends use locking stubs (overridden by our threads libraries). > If I recall correctly, our old a.out based shared lib implementation did it > precicely this way. dlopen() was a function in libc, that called through > a vector into the guts of ld.so.1. The dynamic linker itself never provided > direct call access to this stuff. Some systems put these public functions > in a seperate library, -ldl. The ELF implemetation that we use does, and > doesn't give the threads library a chance to wrap them. > > (And no, this is not an invitation for getting sidetracked on making > ld-elf.so.1 into libdl.so.1 as a service library, etc etc) > > How would things go if we renamed the ld-elf.so functions to __rtld_dlopen() > etc and then had libc provide a weak dlopen() function that redirected to > __rtld_dlopen(), and give libpthread a chance to provide a replacement? > And of course, deal with making the runtime symbol resolution as John > suggested in the commit logs. Or just have libc provide the necessary locking so that we don't need to repeat it in libc_r, libthr, and libpthread. Is a simple mutex around dlopen, dlsym, etc, sufficient? We don't need to handle recursive calls, right? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 14:30: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 732A237B401 for ; Wed, 30 Apr 2003 14:30:14 -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 821E443FA3 for ; Wed, 30 Apr 2003 14:30:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0402.cvx21-bradley.dialup.earthlink.net ([209.179.193.147] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Az5q-0006Bb-00; Wed, 30 Apr 2003 14:26:23 -0700 Message-ID: <3EB03F0C.A884B141@mindspring.com> Date: Wed, 30 Apr 2003 14:24:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030430155126.377792A8A8@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c8375fe25f06e6ca3406de1b23e05bb83ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 21:30:15 -0000 Peter Wemm wrote: > Terry Lambert wrote: > > This is actually used for the *kernel* to map the > > ld.so into the process address space on the processes behalf; it's > > why there's a dlopen() available in static binaries on SVR4. > > Not on the SVR4 (pre-solaris) that I used. The linker didn't generate > the data in static binaries that ld.so needed at runtime. It's "available", not "in libc" 8-) 8-). There's a seperate "libdlopen". -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 14:46:33 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 2937737B401 for ; Wed, 30 Apr 2003 14:46:33 -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 9331943FAF for ; Wed, 30 Apr 2003 14:46:32 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0402.cvx21-bradley.dialup.earthlink.net ([209.179.193.147] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AzPK-0002sW-00; Wed, 30 Apr 2003 14:46:31 -0700 Message-ID: <3EB043BD.1AE8FEEF@mindspring.com> Date: Wed, 30 Apr 2003 14:44:29 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a3c42c0e2d5769155b7fc3826cade3c593caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 21:46:33 -0000 Daniel Eischen wrote: > Is a simple mutex around dlopen, dlsym, etc, sufficient? We don't need > to handle recursive calls, right? I don't know. "Go Solo 2" in chapter 12 suggests a critical section. It also suggests that it's the caller's responsibility, not the libraries, to do the critical sectioning. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 16:35:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE86A37B401 for ; Wed, 30 Apr 2003 16:35:10 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA88843F85 for ; Wed, 30 Apr 2003 16:35:09 -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 h3UNZ8Bg026221; Wed, 30 Apr 2003 19:35:08 -0400 (EDT) Received: from localhost (eischen@localhost)h3UNZ7T0026217; Wed, 30 Apr 2003 19:35:08 -0400 (EDT) Date: Wed, 30 Apr 2003 19:35:07 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 30 Apr 2003 23:35:11 -0000 On Wed, 30 Apr 2003, Daniel Eischen wrote: > On Tue, 29 Apr 2003, Peter Wemm wrote: > > One way I've seen is to have libc and the respective pthreads libraries > > provide the public access to things like dlopen() etc. That way, the > > threads package of your choice does its own serialization of the entry > > points into the dynamic linker guts/internals. As John Polstra said > > earlier, he has some thoughts about how to make the actual lazy symbol > > lookup be thread-safe. > > I think this would work. It could even be done in our libc, just > as malloc, stdio, and friends use locking stubs (overridden by our > threads libraries). > > > If I recall correctly, our old a.out based shared lib implementation did it > > precicely this way. dlopen() was a function in libc, that called through > > a vector into the guts of ld.so.1. The dynamic linker itself never provided > > direct call access to this stuff. Some systems put these public functions > > in a seperate library, -ldl. The ELF implemetation that we use does, and > > doesn't give the threads library a chance to wrap them. > > > > (And no, this is not an invitation for getting sidetracked on making > > ld-elf.so.1 into libdl.so.1 as a service library, etc etc) > > > > How would things go if we renamed the ld-elf.so functions to __rtld_dlopen() > > etc and then had libc provide a weak dlopen() function that redirected to > > __rtld_dlopen(), and give libpthread a chance to provide a replacement? > > And of course, deal with making the runtime symbol resolution as John > > suggested in the commit logs. > > Or just have libc provide the necessary locking so that we don't need > to repeat it in libc_r, libthr, and libpthread. > > Is a simple mutex around dlopen, dlsym, etc, sufficient? We don't need > to handle recursive calls, right? As an experiment, I made the dlfoo calls in rtld-elf weak (__dlfoo -> dlfoo) and then overrode them in libpthread and protected them with mutexes. I can get mozilla to work about 1/2 of the time now, but it still gets stuck in the same state the other 1/2 of the time. This is a bit of an improvement, and seems to indicate (at least to me) that rtld-elf is the culprit. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 17:28: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 DC31E37B401 for ; Wed, 30 Apr 2003 17:28:53 -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 4E50B43FB1 for ; Wed, 30 Apr 2003 17:28:53 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B1wQ-0006RB-00; Wed, 30 Apr 2003 17:28:51 -0700 Message-ID: <3EB0695F.71CA977F@mindspring.com> Date: Wed, 30 Apr 2003 17:25:03 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46442b4a032ab4b4e3f0396e2f697675a667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 00:28:54 -0000 Daniel Eischen wrote: > As an experiment, I made the dlfoo calls in rtld-elf weak > (__dlfoo -> dlfoo) and then overrode them in libpthread > and protected them with mutexes. > > I can get mozilla to work about 1/2 of the time now, but > it still gets stuck in the same state the other 1/2 of > the time. This is a bit of an improvement, and seems to > indicate (at least to me) that rtld-elf is the culprit. Is there maybe a way to get the thread that was running when the process was involuntarily preempted run first, instead of running it based on priority? Netscape, at least, made this assumption for Java and Javascript pages. Alternately, you may try disabling Java* in Mozilla, and see if that keeps you from crashing. Also try not moving the mouse until everything is loaded, and see if that saves you, too. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 17:32: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 7B8A737B401 for ; Wed, 30 Apr 2003 17:32:06 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4D0143FB1 for ; Wed, 30 Apr 2003 17:32:05 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <20030501003204002006jkdte>; Thu, 1 May 2003 00:32:04 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA66600; Wed, 30 Apr 2003 17:32:03 -0700 (PDT) Date: Wed, 30 Apr 2003 17:32:02 -0700 (PDT) From: Julian Elischer To: Terry Lambert In-Reply-To: <3EB0695F.71CA977F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 00:32:06 -0000 What would be cool would be a signal handler for SIGUSR1 or something that dumps out (to somewhere) a full thread state table. On Wed, 30 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > As an experiment, I made the dlfoo calls in rtld-elf weak > > (__dlfoo -> dlfoo) and then overrode them in libpthread > > and protected them with mutexes. > > > > I can get mozilla to work about 1/2 of the time now, but > > it still gets stuck in the same state the other 1/2 of > > the time. This is a bit of an improvement, and seems to > > indicate (at least to me) that rtld-elf is the culprit. > > > Is there maybe a way to get the thread that was running when > the process was involuntarily preempted run first, instead of > running it based on priority? Netscape, at least, made this > assumption for Java and Javascript pages. > > Alternately, you may try disabling Java* in Mozilla, and see > if that keeps you from crashing. > > Also try not moving the mouse until everything is loaded, and > see if that saves you, too. > > -- Terry > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 17:33: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 C567937B401 for ; Wed, 30 Apr 2003 17:33:43 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2652D43FBD for ; Wed, 30 Apr 2003 17:33: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 h410XgBg004942; Wed, 30 Apr 2003 20:33:42 -0400 (EDT) Received: from localhost (eischen@localhost)h410Xgsu004939; Wed, 30 Apr 2003 20:33:42 -0400 (EDT) Date: Wed, 30 Apr 2003 20:33:42 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EB0695F.71CA977F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 00:33:44 -0000 On Wed, 30 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > As an experiment, I made the dlfoo calls in rtld-elf weak > > (__dlfoo -> dlfoo) and then overrode them in libpthread > > and protected them with mutexes. > > > > I can get mozilla to work about 1/2 of the time now, but > > it still gets stuck in the same state the other 1/2 of > > the time. This is a bit of an improvement, and seems to > > indicate (at least to me) that rtld-elf is the culprit. > > > Is there maybe a way to get the thread that was running when > the process was involuntarily preempted run first, instead of > running it based on priority? Netscape, at least, made this > assumption for Java and Javascript pages. Yes, but that breaks other things. The threads library does scheduling based on POSIX scheduling semantics. We don't have support for scheduling similar to what you find in the kernel. This is probably why libthr doesn't have a problem with mozilla. > Alternately, you may try disabling Java* in Mozilla, and see > if that keeps you from crashing. > > Also try not moving the mouse until everything is loaded, and > see if that saves you, too. When it hangs, there's no windowing, so no mouse. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 17:39: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 97B0737B401 for ; Wed, 30 Apr 2003 17:39:53 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D98E943FBF for ; Wed, 30 Apr 2003 17:39:52 -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 h410dmBg006019; Wed, 30 Apr 2003 20:39:48 -0400 (EDT) Received: from localhost (eischen@localhost)h410dlHl006015; Wed, 30 Apr 2003 20:39:47 -0400 (EDT) Date: Wed, 30 Apr 2003 20:39:47 -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: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 00:39:53 -0000 On Wed, 30 Apr 2003, Julian Elischer wrote: > What would be cool would be a signal handler for SIGUSR1 > or something that dumps out (to somewhere) a full thread state table. Where have you been? We've had that in libc_r, libthr (I believe), and libpthread via SIGINFO :-) The problem is that rtld-elf uses sigprocmask to block all the signals within its critical regions, so only SIGKILL works. I've made some local changes to rtld-elf just to test out different theories, but it's beyond me (well, I don't really want to devote lots of time trying to understand all the inner workings of it) to make the kind of changes that jdp had mentioned. > On Wed, 30 Apr 2003, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > As an experiment, I made the dlfoo calls in rtld-elf weak > > > (__dlfoo -> dlfoo) and then overrode them in libpthread > > > and protected them with mutexes. > > > > > > I can get mozilla to work about 1/2 of the time now, but > > > it still gets stuck in the same state the other 1/2 of > > > the time. This is a bit of an improvement, and seems to > > > indicate (at least to me) that rtld-elf is the culprit. > > > > > > Is there maybe a way to get the thread that was running when > > the process was involuntarily preempted run first, instead of > > running it based on priority? Netscape, at least, made this > > assumption for Java and Javascript pages. > > > > Alternately, you may try disabling Java* in Mozilla, and see > > if that keeps you from crashing. > > > > Also try not moving the mouse until everything is loaded, and > > see if that saves you, too. > > > > -- Terry -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 18:11:04 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 0488D37B401 for ; Wed, 30 Apr 2003 18:11:04 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94E5D43F3F for ; Wed, 30 Apr 2003 18:11:03 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 6E20D2A7EA; Wed, 30 Apr 2003 18:11:03 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Date: Wed, 30 Apr 2003 18:11:03 -0700 From: Peter Wemm Message-Id: <20030501011103.6E20D2A7EA@canning.wemm.org> cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 01:11:04 -0000 Daniel Eischen wrote: > On Wed, 30 Apr 2003, Daniel Eischen wrote: > > > On Tue, 29 Apr 2003, Peter Wemm wrote: > > > One way I've seen is to have libc and the respective pthreads libraries > > > provide the public access to things like dlopen() etc. That way, the > > > threads package of your choice does its own serialization of the entry > > > points into the dynamic linker guts/internals. As John Polstra said > > > earlier, he has some thoughts about how to make the actual lazy symbol > > > lookup be thread-safe. > > > > I think this would work. It could even be done in our libc, just > > as malloc, stdio, and friends use locking stubs (overridden by our > > threads libraries). > > > > > If I recall correctly, our old a.out based shared lib implementation did it > > > precicely this way. dlopen() was a function in libc, that called through > > > a vector into the guts of ld.so.1. The dynamic linker itself never provi ded > > > direct call access to this stuff. Some systems put these public function s > > > in a seperate library, -ldl. The ELF implemetation that we use does, and > > > doesn't give the threads library a chance to wrap them. > > > > > > (And no, this is not an invitation for getting sidetracked on making > > > ld-elf.so.1 into libdl.so.1 as a service library, etc etc) > > > > > > How would things go if we renamed the ld-elf.so functions to __rtld_dlope n() > > > etc and then had libc provide a weak dlopen() function that redirected to > > > __rtld_dlopen(), and give libpthread a chance to provide a replacement? > > > And of course, deal with making the runtime symbol resolution as John > > > suggested in the commit logs. > > > > Or just have libc provide the necessary locking so that we don't need > > to repeat it in libc_r, libthr, and libpthread. > > > > Is a simple mutex around dlopen, dlsym, etc, sufficient? We don't need > > to handle recursive calls, right? > > As an experiment, I made the dlfoo calls in rtld-elf weak > (__dlfoo -> dlfoo) and then overrode them in libpthread > and protected them with mutexes. > > I can get mozilla to work about 1/2 of the time now, but > it still gets stuck in the same state the other 1/2 of > the time. This is a bit of an improvement, and seems to > indicate (at least to me) that rtld-elf is the culprit. As John said, the problem is twofold. One is the symbol resolution itself, eg: when you access a function for the first time, a lazy binding call happens. He had ideas about how to make that fully reentrant. The second problem was preventing dlopen() and friends being called in parallel. It sounds like you've dealt with only the second problem... Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 18:35: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 822D537B401 for ; Wed, 30 Apr 2003 18:35:51 -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 9EBC143FBD for ; Wed, 30 Apr 2003 18:35:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B2zD-0005DD-00; Wed, 30 Apr 2003 18:35:48 -0700 Message-ID: <3EB07877.63BD1623@mindspring.com> Date: Wed, 30 Apr 2003 18:29:27 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44f54ad5a6ef34df175f819183c5bcf0ba7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 01:35:51 -0000 Daniel Eischen wrote: > On Wed, 30 Apr 2003, Terry Lambert wrote: > > Daniel Eischen wrote: > > > As an experiment, I made the dlfoo calls in rtld-elf weak > > > (__dlfoo -> dlfoo) and then overrode them in libpthread > > > and protected them with mutexes. > > > > > > I can get mozilla to work about 1/2 of the time now, but > > > it still gets stuck in the same state the other 1/2 of > > > the time. This is a bit of an improvement, and seems to > > > indicate (at least to me) that rtld-elf is the culprit. > > > > Is there maybe a way to get the thread that was running when > > the process was involuntarily preempted run first, instead of > > running it based on priority? Netscape, at least, made this > > assumption for Java and Javascript pages. > > Yes, but that breaks other things. The threads library does > scheduling based on POSIX scheduling semantics. We don't > have support for scheduling similar to what you find in > the kernel. This is probably why libthr doesn't have a > problem with mozilla. Kind of my point... I think it's Mozilla that has a problem, not the threads library. I also think that putting the sync primitive in the dlopen() code making the problem less worse is probably more a result of serialization through the scheduler over preemption, than something that's being fixed by the lock itself. Changing the scheduling would let you confirm or refute that, without having to go through and try to lock everything up, only to find out the reduced problem is a side effect, and you can't make the side effect cure the problem 100% of the time. At that point, it's probably time to start looking at fixing Mozilla, instead of fixing the threads library. BTW: I'm aware of a number of programs that have the problem of "all the world is Linux, Sun, or Windows", and assume that threads will run to completion without being preempted, so long as they have work to do, and had the quantum first. I expect that if they got threads running on SMP systems, with multiple threads running simultaneously, you'll see the same problm with libthr, and with Linux and with Solaris, with these applications... the only thing that it's doing is the same as the dlopen() locks, which is narrowing the race window, rather than eliminating it, in these cases. > > Alternately, you may try disabling Java* in Mozilla, and see > > if that keeps you from crashing. > > > > Also try not moving the mouse until everything is loaded, and > > see if that saves you, too. > > When it hangs, there's no windowing, so no mouse. I mean load a page which would ordinary cause it to hang, and don't move the mose at all while you wait for it to load. No expose events means nothing else to run means effectively single threaded. The Java* disabling suggestion is well worth following up; I don't know if Mozilla does things exactly the same, but the GIF rendering used to be in a thread that was not reentrancy safe. Disabling bot of these effectively disables that engine in Netscape; perhaps it would do the same in Mozilla. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:12: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 9863E37B401 for ; Wed, 30 Apr 2003 19:12:07 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC6543F3F for ; Wed, 30 Apr 2003 19:12:06 -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 h412C5Bg019681; Wed, 30 Apr 2003 22:12:05 -0400 (EDT) Received: from localhost (eischen@localhost)h412C4JX019674; Wed, 30 Apr 2003 22:12:04 -0400 (EDT) Date: Wed, 30 Apr 2003 22:12:04 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EB07877.63BD1623@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:12:07 -0000 On Wed, 30 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > > > When it hangs, there's no windowing, so no mouse. > > I mean load a page which would ordinary cause it to hang, and > don't move the mose at all while you wait for it to load. No > expose events means nothing else to run means effectively > single threaded. It doesn't *get* to the point of having *any* X-window open. In other words, I enter 'mozilla' at the prompt and see nothing at all. After some of my local hacks, it loads 1/2 of the time and once it is loaded, it never hangs. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:16:59 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 003A137B401 for ; Wed, 30 Apr 2003 19:16:58 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AB5E43F85 for ; Wed, 30 Apr 2003 19:16: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 h412GtBg020341; Wed, 30 Apr 2003 22:16:55 -0400 (EDT) Received: from localhost (eischen@localhost)h412GtIX020336; Wed, 30 Apr 2003 22:16:55 -0400 (EDT) Date: Wed, 30 Apr 2003 22:16:54 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030501011103.6E20D2A7EA@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:16:59 -0000 On Wed, 30 Apr 2003, Peter Wemm wrote: > Daniel Eischen wrote: > > As an experiment, I made the dlfoo calls in rtld-elf weak > > (__dlfoo -> dlfoo) and then overrode them in libpthread > > and protected them with mutexes. > > > > I can get mozilla to work about 1/2 of the time now, but > > it still gets stuck in the same state the other 1/2 of > > the time. This is a bit of an improvement, and seems to > > indicate (at least to me) that rtld-elf is the culprit. > > As John said, the problem is twofold. One is the symbol resolution itself, > eg: when you access a function for the first time, a lazy binding call > happens. He had ideas about how to make that fully reentrant. The second > problem was preventing dlopen() and friends being called in parallel. It > sounds like you've dealt with only the second problem... Yep, I know. I just want to provide more evidence that it is rtld, and not something we're doing in libpthread. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:28: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 C240C37B401 for ; Wed, 30 Apr 2003 19:28:58 -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 2582F43F3F for ; Wed, 30 Apr 2003 19:28:58 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B3oc-0000zp-00; Wed, 30 Apr 2003 19:28:55 -0700 Message-ID: <3EB0845A.FA34BA04@mindspring.com> Date: Wed, 30 Apr 2003 19:20:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030501011103.6E20D2A7EA@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4597a39441ee09a0dc8aa378bbcc7e9f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:28:59 -0000 Peter Wemm wrote: > As John said, the problem is twofold. One is the symbol resolution itself, > eg: when you access a function for the first time, a lazy binding call > happens. He had ideas about how to make that fully reentrant. It doesn't need to be; the pointer update is atomic, so it's safe for two threads in the same process at the same time (or there would have been much more spectacular fireworks, before now), and if it happens over a fork(), then the child process gets a stale copy, and does the lazy binding call itself, triggering a COW in the page where the lazy-bound verion should have been. Either way, it still works (you just get an extra page in the child that you wouldn't have had, had you waited). > The second problem was preventing dlopen() and friends being > called in parallel. It sounds like you've dealt with only the > second problem... I don't think the first problem needs to be dealt with at all; I don't think dealing with the second problem is something you want anyway (see other post, and see chapter 12 of the corrigenda). I think the real prolem is that the threaded code in question is broken, and thinks that the thread that was involuntarily preempted should be restarted, instead of the highest priority thread available, when it gets its next quantum. In other words, the code was written to expect a specific type of pthreads implementation, and is failing to comply with POSIX. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:30: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 9C33737B401 for ; Wed, 30 Apr 2003 19:30:19 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F339D43F85 for ; Wed, 30 Apr 2003 19:30: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 h412UIBg022252; Wed, 30 Apr 2003 22:30:18 -0400 (EDT) Received: from localhost (eischen@localhost)h412UHml022248; Wed, 30 Apr 2003 22:30:17 -0400 (EDT) Date: Wed, 30 Apr 2003 22:30:17 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:30:19 -0000 On Wed, 30 Apr 2003, Daniel Eischen wrote: > On Wed, 30 Apr 2003, Terry Lambert wrote: > > Daniel Eischen wrote: > > > > > > When it hangs, there's no windowing, so no mouse. > > > > I mean load a page which would ordinary cause it to hang, and > > don't move the mose at all while you wait for it to load. No > > expose events means nothing else to run means effectively > > single threaded. > > It doesn't *get* to the point of having *any* X-window open. > In other words, I enter 'mozilla' at the prompt and see > nothing at all. After some of my local hacks, it loads > 1/2 of the time and once it is loaded, it never hangs. And in answer to your other question. If I hack the threads library to always resume a thread that has an expired quantum, mozilla seems to work just fine -- I can't get it to fail. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:35: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 214B237B40A for ; Wed, 30 Apr 2003 19:35:45 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 596F343F3F for ; Wed, 30 Apr 2003 19:35:44 -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 h412ZhBg022979; Wed, 30 Apr 2003 22:35:43 -0400 (EDT) Received: from localhost (eischen@localhost)h412Zhst022974; Wed, 30 Apr 2003 22:35:43 -0400 (EDT) Date: Wed, 30 Apr 2003 22:35:43 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EB0845A.FA34BA04@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:35:45 -0000 > Peter Wemm wrote: > > As John said, the problem is twofold. One is the symbol resolution itself, > > eg: when you access a function for the first time, a lazy binding call > > happens. He had ideas about how to make that fully reentrant. > > It doesn't need to be; the pointer update is atomic, so it's safe I don't think it is atomic. Take a look at rtld-elf.c. > for two threads in the same process at the same time (or there > would have been much more spectacular fireworks, before now), and > if it happens over a fork(), then the child process gets a stale > copy, and does the lazy binding call itself, triggering a COW in > the page where the lazy-bound verion should have been. Either way, > it still works (you just get an extra page in the child that you > wouldn't have had, had you waited). It works in libc_r because libc_r uses signals for its scheduling quantum and rtld masks out signals while holding write locks. It works in libthr (I'm assuming) because the kernel doesn't use POSIX scheduling and always makes sure each thread gets quantum. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:39: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 EBA3737B401 for ; Wed, 30 Apr 2003 19:39:52 -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 68C8043F85 for ; Wed, 30 Apr 2003 19:39:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B3zC-0003BG-00; Wed, 30 Apr 2003 19:39:51 -0700 Message-ID: <3EB086B5.2BE64567@mindspring.com> Date: Wed, 30 Apr 2003 19:30:13 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4597a39441ee09a0d1545798e5fff671f387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:39:53 -0000 Daniel Eischen wrote: > On Wed, 30 Apr 2003, Terry Lambert wrote: > > Daniel Eischen wrote: > > > When it hangs, there's no windowing, so no mouse. > > > > I mean load a page which would ordinary cause it to hang, and > > don't move the mose at all while you wait for it to load. No > > expose events means nothing else to run means effectively > > single threaded. > > It doesn't *get* to the point of having *any* X-window open. > In other words, I enter 'mozilla' at the prompt and see > nothing at all. After some of my local hacks, it loads > 1/2 of the time and once it is loaded, it never hangs. OK, so the initializatio is hanging, not the application itself; it wasn't clear to me from your posts that Mozilla was not even loading, only that it was hanging (which to me means that it's running and then it stops running). I'd like to make the same suggestions with regard to Java* and not moving the mouse or typing at all while it's tring to load. That's probably not doing to make it work, but it will give us some information: it will say that it's not a user event that caused the problem. Another thing you might try is to cause Xevents to be synchronous (this is a debug option, eiher via libX11, or in the X server startup). I'd also like to make the same suggestion with regard to the threads scheduling, to see if it's a bad asumption in the mozilla code about object or code reentrancy being protected against preemption. The reason I'd like to see this is that, as you point out, it works fine with libthr, which has this assumption, at least on UP machines. I'd also like to see someone with an SMP box using libthr who has a problem with Mozilla... ;^)... but that can wait, I guess. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:42:01 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A451937B401 for ; Wed, 30 Apr 2003 19:42:01 -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 3138643F75 for ; Wed, 30 Apr 2003 19:42:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B41G-0003Ye-00; Wed, 30 Apr 2003 19:41:59 -0700 Message-ID: <3EB0872E.A4C1ADE@mindspring.com> Date: Wed, 30 Apr 2003 19:32:14 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4597a39441ee09a0deacbe988146e839aa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:42:02 -0000 Daniel Eischen wrote: > Yep, I know. I just want to provide more evidence that > it is rtld, and not something we're doing in libpthread. The only way to do that is t make it go away 100% of the time by hacking rtld. I don't believe you are going to be able to do that, because a conforming threads-using POSIX application wouldn't care about that anyway. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 30 19:47: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 0049E37B401 for ; Wed, 30 Apr 2003 19:47:06 -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 4AFDF43F85 for ; Wed, 30 Apr 2003 19:47:05 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx22-bradley.dialup.earthlink.net ([209.179.198.55] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19B46B-0004ZS-00; Wed, 30 Apr 2003 19:47:04 -0700 Message-ID: <3EB08854.67A7BDA@mindspring.com> Date: Wed, 30 Apr 2003 19:37:08 -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: b1a02af9316fbb217a47c185c03b154d40683398e744b8a498e23b242c4828aa81508753e9343e90387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 01 May 2003 02:47:07 -0000 Daniel Eischen wrote: > And in answer to your other question. If I hack the threads > library to always resume a thread that has an expired quantum, > mozilla seems to work just fine -- I can't get it to fail. Thanks. I now claim authoritatively that according to POSIX, this is a coding error in Mozilla. I also claim that "fixing" dlopen is insufficient, and that the error will pop up in some other interface, such as mmap() or shmat(), etc., which will have exactly the same issues. For bonus points, it should be possible to save the preempted thread's ID, and, when an involuntary switch would have occurred, print out the program counter of the thread that gets preempted without this patch, but doesn't get preempted with it. That will tell you exactly what code is failing, every time. I submit the theory that it's not going to be dl*() every time. -- Terry From owner-freebsd-threads@FreeBSD.ORG Thu May 1 13:21: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 B765A37B401; Thu, 1 May 2003 13:21:05 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836FB43FAF; Thu, 1 May 2003 13:21:04 -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 h41KKuBg029130; Thu, 1 May 2003 16:20:56 -0400 (EDT) Received: from localhost (eischen@localhost)h41KKuUn029126; Thu, 1 May 2003 16:20:56 -0400 (EDT) Date: Thu, 1 May 2003 16:20:56 -0400 (EDT) From: Daniel Eischen To: Vallo Kallaste In-Reply-To: <20030501200911.GA721@kevad.internal> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: threads@freebsd.org cc: Julian Elischer Subject: Re: libkse observations [Was: Re: libthr broken] 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, 01 May 2003 20:21:06 -0000 On Thu, 1 May 2003, Vallo Kallaste wrote: > On Wed, Apr 30, 2003 at 11:25:04AM -0400, Daniel Eischen > wrote: > > > I just committed a fix for this. I can now run knode, although I > > get: > > > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > kdecore (KAction): WARNING: KAction::plugAccel(): call to deprecated action. > > > > I am running kde3.1 but built with X 4.2.99 from the XFree86 CVS tree (not > > via the port), so that may have something to do with it. > > The kdecore messages are harmless and present even with libc_r. > Now KNode starts up and is useable as before and the same bugs as > before remain. I have configured KNode to start up external editor > (gvim), which it does. After editing and :wq KNode still thinks that > external editor is running while it's long gone. The text from the > temporary file (/tmp/kde-vallo/knode?????) will not be transferred > to KNode's native text editor window. Closing KNode gets rid of the > KNode UI, but it remains running accordingly to ps and top. It has > no state per top and is killable via TERM. I think there is something wrong with SIGCHLD not getting properly sent/received to libkse processes, or perhaps libkse just doesn't dispatch the signal correctly. > Mozilla still will not start up. It's present in the process table > but no UI will show up. Top will show mozilla process steadily in > the RUN state, using zero CPU and it's not killable via TERM. This is a bug in rtld-elf as discussed earlier on this list (threads@). It isn't thread-safe and the tricks it uses to prevent thread swap-out work for libc_r, but not for libkse. This problem was just added to the TODO list for 5.1-release. Here's a hack to libpthread to temporarily get around this problem, though it might cause other problems (allowing CPU hungry threads to starve other threads). -- Dan Eischen Index: thread/thr_kern.c =================================================================== RCS file: /home/ncvs/src/lib/libpthread/thread/thr_kern.c,v retrieving revision 1.62 diff -u -r1.62 thr_kern.c --- thread/thr_kern.c 30 Apr 2003 15:05:17 -0000 1.62 +++ thread/thr_kern.c 1 May 2003 20:19:02 -0000 @@ -784,7 +784,8 @@ if (curthread == NULL) ; /* Nothing to do here. */ else if ((curthread->need_switchout == 0) && - (curthread->blocked == 0) && (THR_IN_CRITICAL(curthread))) { + (curthread->blocked == 0) && + ((THR_IN_CRITICAL(curthread)) || (curthread->state == PS_RUNNING))) { /* * Resume the thread and tell it to yield when * it leaves the critical region. From owner-freebsd-threads@FreeBSD.ORG Thu May 1 17:23:17 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D65537B401 for ; Thu, 1 May 2003 17:23:17 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C0343FA3 for ; Thu, 1 May 2003 17:23:17 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id CB0BA2A7EA; Thu, 1 May 2003 17:23:16 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Date: Thu, 01 May 2003 17:23:16 -0700 From: Peter Wemm Message-Id: <20030502002316.CB0BA2A7EA@canning.wemm.org> cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 00:23:17 -0000 Daniel Eischen wrote: > On Wed, 30 Apr 2003, Terry Lambert wrote: > > Daniel Eischen wrote: > > > > > > When it hangs, there's no windowing, so no mouse. > > > > I mean load a page which would ordinary cause it to hang, and > > don't move the mose at all while you wait for it to load. No > > expose events means nothing else to run means effectively > > single threaded. > > It doesn't *get* to the point of having *any* X-window open. > In other words, I enter 'mozilla' at the prompt and see > nothing at all. After some of my local hacks, it loads > 1/2 of the time and once it is loaded, it never hangs. Here's a thought. Have a look at the _umtx_lock() and _umtx_unlock() syscalls that were recently added, and the corresponding scaffolding in libthr. Although this would likely break libc_r, it might be worth an experiment to reimplement the ld-elf.so.1 spinlocks using that and see how it goes. In the contested case, it would tsleep() the thread rather than have it sit in a spinloop. Hmm. On second thoughts, this might not be so easy since it needs a thread identifier. But have a peek anyway and see if there is anything to be had from there.. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri May 2 01:10:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0774B37B401 for ; Fri, 2 May 2003 01:10:36 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 891BC43FCB for ; Fri, 2 May 2003 01:10:35 -0700 (PDT) (envelope-from CooCooCaChoo@myrealbox.com) Received: from 055.a.001.cba.iprimus.net.au (210.50.171.55) by smtp01.syd.iprimus.net.au (7.0.012) id 3E96D1D200351884 for freebsd-threads@freebsd.org; Fri, 2 May 2003 18:10:33 +1000 From: Matthew Gardiner To: freebsd-threads@freebsd.org Date: Fri, 2 May 2003 18:10:38 +1000 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305021810.38170.CooCooCaChoo@myrealbox.com> Subject: Status of KSE and libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 08:10:36 -0000 I've just had a quick look at the cvs and the kse webpage, and it appears from what I see on the CVS that the KSE page is a little out of date. Does anyone have an time line/guess of how far away a fully implementation is of libpthreads and KSE? Matthew Gardiner From owner-freebsd-threads@FreeBSD.ORG Fri May 2 06:10:24 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 4C3A237B401 for ; Fri, 2 May 2003 06:10:24 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB1C43F75 for ; Fri, 2 May 2003 06:10:23 -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 h42DAMBg027792; Fri, 2 May 2003 09:10:22 -0400 (EDT) Received: from localhost (eischen@localhost)h42DAMlF027789; Fri, 2 May 2003 09:10:22 -0400 (EDT) Date: Fri, 2 May 2003 09:10:21 -0400 (EDT) From: Daniel Eischen To: Matthew Gardiner In-Reply-To: <200305021810.38170.CooCooCaChoo@myrealbox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Status of KSE and libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 13:10:24 -0000 On Fri, 2 May 2003, Matthew Gardiner wrote: > I've just had a quick look at the cvs and the kse webpage, and it appears from > what I see on the CVS that the KSE page is a little out of date. I'll look into updating it. > Does anyone have an time line/guess of how far away a fully implementation is > of libpthreads and KSE? We can run alot of threaded programs right now. There are two known problems. Signals aren't quite right yet, and rtld-elf isn't thread-safe and causes hangs loading some applications (like mozilla). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri May 2 11:32: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 A850637B401; Fri, 2 May 2003 11:32:07 -0700 (PDT) Received: from net1.gendyn.com (gate1.gendyn.com [204.60.171.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A781343FBD; Fri, 2 May 2003 11:32:06 -0700 (PDT) (envelope-from deischen@freebsd.org) Received: from [153.11.11.3] (helo=ebnext01) by net1.gendyn.com with esmtp (Exim 2.12 #1) id 19BfK9-0008rj-00; Fri, 2 May 2003 14:31:57 -0400 Received: from clcrtr.gdeb.com ([153.11.109.11]) by ebnext01 with SMTP id h42IVuGR036442; Fri, 2 May 2003 14:31:56 -0400 Received: from freebsd.org (gpz.clc.gdeb.com [192.168.3.12]) by clcrtr.gdeb.com (8.11.4/8.11.4) with ESMTP id h3U2inq87466; Tue, 29 Apr 2003 22:44:50 -0400 (EDT) (envelope-from deischen@freebsd.org) Sender: eghk@clcrtr.gdeb.com Message-ID: <3EB2B97C.F56F4ED5@freebsd.org> Date: Fri, 02 May 2003 14:31:24 -0400 From: Daniel Eischen X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: java@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Java and native threads using libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:32:08 -0000 [Followups to threads@ please] I know you guys have made a lot of progress with native threading using libc_r, but I'd like to see you try out libpthread (libkse) at some point. We're currently in active development of libpthread, so if you have any desires, please let us know. One of the things I'd like to see is removal any knowledge of thread library internals (if you still have any). For instance, if you need to retrieve a thread's register set, I'd rather give you a function to retrieve them instead of knowing where they are in the thread structure. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri May 2 11:34: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 A6F4537B401 for ; Fri, 2 May 2003 11:34:07 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB5943F85 for ; Fri, 2 May 2003 11:34:03 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h42IXd518522; Fri, 2 May 2003 14:33:39 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Fri, 2 May 2003 14:33:39 -0400 (EDT) From: Jeff Roberson To: Peter Wemm In-Reply-To: <20030502002316.CB0BA2A7EA@canning.wemm.org> Message-ID: <20030502143129.N55924-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Daniel Eischen Subject: Re: Question about rtld-elf. Anyone?.. Anyone? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:34:07 -0000 On Thu, 1 May 2003, Peter Wemm wrote: > Daniel Eischen wrote: > > On Wed, 30 Apr 2003, Terry Lambert wrote: > > > Daniel Eischen wrote: > > > > > > > > When it hangs, there's no windowing, so no mouse. > > > > > > I mean load a page which would ordinary cause it to hang, and > > > don't move the mose at all while you wait for it to load. No > > > expose events means nothing else to run means effectively > > > single threaded. > > > > It doesn't *get* to the point of having *any* X-window open. > > In other words, I enter 'mozilla' at the prompt and see > > nothing at all. After some of my local hacks, it loads > > 1/2 of the time and once it is loaded, it never hangs. > > Here's a thought. Have a look at the _umtx_lock() and _umtx_unlock() > syscalls that were recently added, and the corresponding scaffolding in > libthr. Although this would likely break libc_r, it might be worth an > experiment to reimplement the ld-elf.so.1 spinlocks using that and see how > it goes. In the contested case, it would tsleep() the thread rather than > have it sit in a spinloop. Hmm. On second thoughts, this might not be > so easy since it needs a thread identifier. But have a peek anyway and > see if there is anything to be had from there.. > > Cheers, > -Peter I can't remember if we left thr_self() in the api but this call can be made from any application. The thread identifier is just the kva pointer to your thread structure. Actually, I'm almost certain that we left it in. umtx has one bug though, so be careful. Right now it uses the proc lock to protect the blocked thread queue. If casuptr faults while the proc lock is held we would recurse on it in the fault handler. Cheers, Jeff From owner-freebsd-threads@FreeBSD.ORG Fri May 2 11:41:33 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 326B037B401 for ; Fri, 2 May 2003 11:41:33 -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 5E77743FE3 for ; Fri, 2 May 2003 11:41:32 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h42IfVnT000141 for ; Fri, 2 May 2003 14:41:31 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h42IfVnj000139; Fri, 2 May 2003 14:41:31 -0400 (EDT) Date: Fri, 2 May 2003 14:41:31 -0400 From: Alexander Kabaev To: threads@freebsd.org Message-Id: <20030502144131.08602795.ak03@gte.com> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws90 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FYI: rtld locking and TLS X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:41:33 -0000 I am working on ELF TLS implementation in rtld and have an idea on how TLS can be used to make rtld more friendly to various threading implementations we have in the tree today. This is a heads up to avoid stomping on each other if anyone else is doing something similar. -- Alexander Kabaev From owner-freebsd-threads@FreeBSD.ORG Fri May 2 11:58: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 9111F37B407 for ; Fri, 2 May 2003 11:58:35 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C1BC43FB1 for ; Fri, 2 May 2003 11:58:35 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id B5EF32A7EA; Fri, 2 May 2003 11:58:34 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alexander Kabaev In-Reply-To: <20030502144131.08602795.ak03@gte.com> Date: Fri, 02 May 2003 11:58:34 -0700 From: Peter Wemm Message-Id: <20030502185834.B5EF32A7EA@canning.wemm.org> cc: threads@freebsd.org Subject: Re: FYI: rtld locking and TLS X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:58:36 -0000 Alexander Kabaev wrote: > I am working on ELF TLS implementation in rtld and have an idea on how > TLS can be used to make rtld more friendly to various threading > implementations we have in the tree today. This is a heads up to avoid > stomping on each other if anyone else is doing something similar. All right!!! Thank you! :-) Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri May 2 11:58:46 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 100CD37B401; Fri, 2 May 2003 11:58:46 -0700 (PDT) Received: from relay1.cris.net (relay1.cris.net [212.110.128.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387C943FAF; Fri, 2 May 2003 11:58:42 -0700 (PDT) (envelope-from ml@phantom.cris.net) Received: from phantom.cris.net (root@phantom.cris.net [212.110.130.74]) by relay1.cris.net (8.12.6/8.12.6) with ESMTP id h42L5wSO027543; Fri, 2 May 2003 21:05:59 GMT Received: (from ml@localhost) by phantom.cris.net (8.12.6/8.12.2) id h42J5MX4092643; Fri, 2 May 2003 22:05:22 +0300 (EEST) (envelope-from ml) Date: Fri, 2 May 2003 22:05:22 +0300 From: Alexey Zelkin To: Daniel Eischen Message-ID: <20030502220522.A92621@phantom.cris.net> References: <3EB2B97C.F56F4ED5@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3EB2B97C.F56F4ED5@freebsd.org>; from deischen@freebsd.org on Fri, May 02, 2003 at 02:31:24PM -0400 X-Operating-System: FreeBSD 4.7-STABLE i386 cc: java@freebsd.org cc: threads@freebsd.org Subject: Re: Java and native threads using libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:58:46 -0000 hi, I am catching up with jdk14 port issues now and 'libkse' is one of top items on my TODO list. I'll let you know results as soon as have some. On Fri, May 02, 2003 at 02:31:24PM -0400, Daniel Eischen wrote: > [Followups to threads@ please] > > I know you guys have made a lot of progress with native threading > using libc_r, but I'd like to see you try out libpthread (libkse) > at some point. > > We're currently in active development of libpthread, so if you > have any desires, please let us know. One of the things I'd like > to see is removal any knowledge of thread library internals (if > you still have any). For instance, if you need to retrieve a > thread's register set, I'd rather give you a function to retrieve > them instead of knowing where they are in the thread structure. > > -- > Dan Eischen > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Fri May 2 23:51:55 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A304137B401; Fri, 2 May 2003 23:51:55 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7949D43F85; Fri, 2 May 2003 23:51:53 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 19BpIC-00063N-00; Fri, 2 May 2003 22:10:36 -0700 Date: Fri, 2 May 2003 22:10:35 -0700 (PDT) From: Tom Samplonius To: Daniel Eischen In-Reply-To: <3EB2B97C.F56F4ED5@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: java@freebsd.org cc: threads@freebsd.org Subject: Re: Java and native threads using libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 06:51:56 -0000 On Fri, 2 May 2003, Daniel Eischen wrote: > I know you guys have made a lot of progress with native threading > using libc_r, but I'd like to see you try out libpthread (libkse) > at some point. What kind of implmentation is libpthread? M:N or 1:1? freebsd-current has had several lengthy discussion about various competing available, proposed, or planned threading implemenations. I couldn't determine from the archives what the conclusion was. I hoping for a summary of what libpthread does now. ... > -- > Dan Eischen > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Sat May 3 00:02: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 A77A437B401; Sat, 3 May 2003 00:02:19 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A14D43F85; Sat, 3 May 2003 00:02:19 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h436x9Z19181; Fri, 2 May 2003 23:59:09 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id AAA29092; Sat, 3 May 2003 00:02:15 -0700 (PDT) Message-ID: <3EB368D0.7050208@btc.adaptec.com> Date: Sat, 03 May 2003 00:59:28 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Samplonius References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: java@freebsd.org cc: threads@freebsd.org Subject: Re: Java and native threads using libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 07:02:20 -0000 Tom Samplonius wrote: > On Fri, 2 May 2003, Daniel Eischen wrote: > > >>I know you guys have made a lot of progress with native threading >>using libc_r, but I'd like to see you try out libpthread (libkse) >>at some point. > > > What kind of implmentation is libpthread? M:N or 1:1? freebsd-current > has had several lengthy discussion about various competing available, > proposed, or planned threading implemenations. I couldn't determine from > the archives what the conclusion was. I hoping for a summary of what > libpthread does now. > > ... > libpthread was recently renamed back to libkse to avoid confusion until it is ready for prime-time. It is M:N. libthr is 1:1. Both are not ready for prime-time, especially with SMP, but it still might be interesting to test them on UP systems. I tried jdk13 with libthr last month and had mixed results. SwingSet2 ran pretty well, but the mozilla plugin didn't. I haven't tried libkse yet since it deadlocks quite quickly in rtld. Scott From owner-freebsd-threads@FreeBSD.ORG Sat May 3 05:55: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 51A3337B401 for ; Sat, 3 May 2003 05:55:57 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5A9C43F85 for ; Sat, 3 May 2003 05:55: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 h43CtsBg006002; Sat, 3 May 2003 08:55:54 -0400 (EDT) Received: from localhost (eischen@localhost)h43Cts0C005998; Sat, 3 May 2003 08:55:54 -0400 (EDT) Date: Sat, 3 May 2003 08:55:53 -0400 (EDT) From: Daniel Eischen To: Scott Long In-Reply-To: <3EB368D0.7050208@btc.adaptec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Tom Samplonius Subject: Re: Java and native threads using libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 12:55:57 -0000 On Sat, 3 May 2003, Scott Long wrote: > Tom Samplonius wrote: > > On Fri, 2 May 2003, Daniel Eischen wrote: > > > > > >>I know you guys have made a lot of progress with native threading > >>using libc_r, but I'd like to see you try out libpthread (libkse) > >>at some point. > > > > > > What kind of implmentation is libpthread? M:N or 1:1? freebsd-current > > has had several lengthy discussion about various competing available, > > proposed, or planned threading implemenations. I couldn't determine from > > the archives what the conclusion was. I hoping for a summary of what > > libpthread does now. > > > > ... > > > > libpthread was recently renamed back to libkse to avoid confusion until > it is ready for prime-time. It is M:N. libthr is 1:1. Both are not > ready for prime-time, especially with SMP, but it still might be > interesting to test them on UP systems. I tried jdk13 with libthr last > month and had mixed results. SwingSet2 ran pretty well, but the > mozilla plugin didn't. I haven't tried libkse yet since it deadlocks > quite quickly in rtld. I posted a patch to libpthread a couple of days ago that helps work around this problem; you might want to try that. I believe the Java implementation relies on libc_r internals, which aren't the same in libpthread (and perhaps libthr too). I wouldn't expect copying libthr or libpthread to libc_r to work for the JVM because of this. Perhaps this isn't true anymore, though... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat May 3 09:12:17 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D06FF37B401 for ; Sat, 3 May 2003 09:12:17 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67BF43F75 for ; Sat, 3 May 2003 09:12:16 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id CA8692ED417; Sat, 3 May 2003 09:12:15 -0700 (PDT) Date: Sat, 3 May 2003 09:12:15 -0700 From: Jon Mini To: Daniel Eischen Message-ID: <20030503161215.GC20512@elvis.mu.org> References: <200305021810.38170.CooCooCaChoo@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: Status of KSE and libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 16:12:18 -0000 Daniel Eischen [eischen@pcnet1.pcnet.com] wrote : > On Fri, 2 May 2003, Matthew Gardiner wrote: > > > I've just had a quick look at the cvs and the kse webpage, > > and it appears from what I see on the CVS that the KSE page >> is a little out of date. > > I'll look into updating it. Dan, since you seem the be the one doing most of the work on libpthread right now, I think it would make the most sense if you kept the kse page up to date. -- Jonathan Mini http://www.freebsd.org/ From owner-freebsd-threads@FreeBSD.ORG Sat May 3 11:30:44 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 4F52837B401; Sat, 3 May 2003 11:30:44 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838B243F93; Sat, 3 May 2003 11:30: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 h43IUgBg021717; Sat, 3 May 2003 14:30:42 -0400 (EDT) Received: from localhost (eischen@localhost)h43IUgau021714; Sat, 3 May 2003 14:30:42 -0400 (EDT) Date: Sat, 3 May 2003 14:30:42 -0400 (EDT) From: Daniel Eischen To: Jon Mini In-Reply-To: <20030503161215.GC20512@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Status of KSE and libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 18:30:44 -0000 On Sat, 3 May 2003, Jon Mini wrote: > Daniel Eischen [eischen@pcnet1.pcnet.com] wrote : > > > On Fri, 2 May 2003, Matthew Gardiner wrote: > > > > > I've just had a quick look at the cvs and the kse webpage, > > > and it appears from what I see on the CVS that the KSE page > >> is a little out of date. > > > > I'll look into updating it. > > Dan, since you seem the be the one doing most of the work on > libpthread right now, I think it would make the most sense if > you kept the kse page up to date. Yep, thanks for reminding me. It was on my list of things to do; I'll try to get to it ASAP. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat May 3 23:45:24 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 4769D37B401 for ; Sat, 3 May 2003 23:45:24 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4CF43FAF for ; Sat, 3 May 2003 23:45:23 -0700 (PDT) (envelope-from CooCooCaChoo@myrealbox.com) Received: from matthewgtyg95c (210.50.172.27) by smtp01.syd.iprimus.net.au (7.0.012) id 3E96D1D20038A678 for freebsd-threads@freebsd.org; Sun, 4 May 2003 16:45:20 +1000 Message-ID: <001101c31208$bee23540$1bac32d2@matthewgtyg95c> From: "Matthew Gardiner" To: References: <200305021810.38170.CooCooCaChoo@myrealbox.com> <20030503161215.GC20512@elvis.mu.org> Date: Sun, 4 May 2003 16:45:25 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Status of KSE and libpthreads 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 06:45:24 -0000 ----- Original Message ----- From: "Jon Mini" To: "Daniel Eischen" Cc: "Matthew Gardiner" ; Sent: Sunday, May 04, 2003 2:12 AM Subject: Re: Status of KSE and libpthreads > Daniel Eischen [eischen@pcnet1.pcnet.com] wrote : > > > On Fri, 2 May 2003, Matthew Gardiner wrote: > > > > > I've just had a quick look at the cvs and the kse webpage, > > > and it appears from what I see on the CVS that the KSE page > >> is a little out of date. > > > > I'll look into updating it. > > Dan, since you seem the be the one doing most of the work on > libpthread right now, I think it would make the most sense if > you kept the kse page up to date. Just had a look at the old website and it appears that is has been updated, awsome! If any FreeBSD core team are reading this, please push back the 5.2 release to around Novemeber-December. The current time frame is bloody rediculous. If libpthread, KSE and a decent amount of SMP aren't done then it makes the 5.x series completely worthless. Things like the fine graining of components are can done gradually, however, with that being said, the key "features" that were touted in the 5.x should be finished such as KSE and libpthread, the SMP can be gradually implemented. Matthew Gardiner