From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 00:40:30 2005 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 C3E8316A4CE; Sun, 20 Feb 2005 00:40:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9637443D3F; Sun, 20 Feb 2005 00:40:30 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1K0eSN0094902; Sun, 20 Feb 2005 00:40:29 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4217DD2A.4030603@freebsd.org> Date: Sun, 20 Feb 2005 08:43:22 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: thread accounting in 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: Sun, 20 Feb 2005 00:40:30 -0000 Daniel Eischen wrote: > ... > >since it will be the only thread in the queue. If N threads >complete (assuming they are all at the same priority) then >the first thread pulled from the completed list will be >run first since it will be the first thread added to the >run queue. > > > note that kernel adds completed thread in reversed order. From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 11:19:52 2005 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 D5E4916A4CE; Sun, 20 Feb 2005 11:19:52 +0000 (GMT) Received: from mx.highway.ne.jp (pip7.usen.ad.jp [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9284243D55; Sun, 20 Feb 2005 11:19:50 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1D2p7s-0008IR-FO; Sun, 20 Feb 2005 20:19:48 +0900 Message-ID: <42187232.2060308@highway.ne.jp> Date: Sun, 20 Feb 2005 20:19:14 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: thread accounting in 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: Sun, 20 Feb 2005 11:19:52 -0000 Daniel Eischen wrote: >If there was no running thread before kse_wait(), then after >kse_wait() returns and if there are completed threads, then >either one thread completed or N threads completed. Either >way, they are all added to the end of the run queue. But >the run queue must have been empty to begin with, otherwise >kse_wait() would not have been called. So it doesn't matter >whether they are added to the head or the end of the queue. >If one thread completes, then it will be run right away >since it will be the only thread in the queue. If N threads >complete (assuming they are all at the same priority) then >the first thread pulled from the completed list will be >run first since it will be the first thread added to the >run queue. > > > Did you try to run the program attached to my past mail? If you run it under X11 terminal on a UP machine, you probably get a unfair result. I traced the program, and so I have noticed that the program repeats the following operations: thread 00 is switched in thread 00 outputs many lines thread 00 is blocked in the kernel thread 01 is switched in thread 01 outputs 1 line thread 01 is blocked in the kernel thread 02 is switched in thread 02 outputs 1 line thread 02 is blocked in the kernel thread 03 is switched in thread 03 outputs 1 line thread 03 is blocked in the kernel thread 04 is switched in thread 04 outputs 1 line thread 04 is blocked in the kernel kse_wait() is called because there is no thread ready to run we return from kse_wait(), and kse_check_completed() is called we add thread 04 to the tail of run queue we add thread 03 to the tail of run queue we add thread 02 to the tail of run queue we add thread 01 to the tail of run queue we add thread 00 to the tail of run queue we return from kse_check_completed() thread 04 is switched in thread 04 outputs many lines thread 04 is blocked in the kernel thread 03 is switched in thread 03 outputs 1 line thread 03 is blocked in the kernel thread 02 is switched in thread 02 outputs 1 line thread 02 is blocked in the kernel thread 01 is switched in thread 01 outputs 1 line thread 01 is blocked in the kernel thread 00 is switched in thread 00 outputs 1 line thread 00 is blocked in the kernel kse_wait() is called because there is no thread ready to run we return from kse_wait(), and kse_check_completed() is called we add thread 00 to the tail of run queue we add thread 01 to the tail of run queue we add thread 02 to the tail of run queue we add thread 03 to the tail of run queue we add thread 04 to the tail of run queue we return from kse_check_completed() Because the program repeats the above operations, I get a result: -------------------- thread 00: 55666 thread 01: 1161 thread 02: 1112 thread 03: 1112 thread 04: 55494 -------------------- Is this a expected result? At least this is not for me. It seems unfair. As we just add completed threads to the tail of run queue in the order which kernel returns, thread 00 and thread 04 get much time slice... -------------------- Kazuaki Oda From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 15:57:07 2005 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 C5EFB16A4CE for ; Sun, 20 Feb 2005 15:57:07 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5334E43D31 for ; Sun, 20 Feb 2005 15:57:07 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1KFv3Gp008783; Sun, 20 Feb 2005 10:57:04 -0500 (EST) Date: Sun, 20 Feb 2005 10:57:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kazuaki Oda In-Reply-To: <42187232.2060308@highway.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2005 15:57:07 -0000 On Sun, 20 Feb 2005, Kazuaki Oda wrote: > Daniel Eischen wrote: > > >If there was no running thread before kse_wait(), then after > >kse_wait() returns and if there are completed threads, then > >either one thread completed or N threads completed. Either > >way, they are all added to the end of the run queue. But > >the run queue must have been empty to begin with, otherwise > >kse_wait() would not have been called. So it doesn't matter > >whether they are added to the head or the end of the queue. > >If one thread completes, then it will be run right away > >since it will be the only thread in the queue. If N threads > >complete (assuming they are all at the same priority) then > >the first thread pulled from the completed list will be > >run first since it will be the first thread added to the > >run queue. > > Did you try to run the program attached to my past mail? If you run it > under X11 terminal on a UP machine, you probably get a unfair result. I don't get much of a difference with and without patch at end. Depending on what your threads are blocking on, I think it can be random. with patch ---------- thread 00: 4716 thread 01: 4307 thread 02: 3631 thread 03: 3698 thread 04: 3455 without patch ------------- thread 00: 4289 thread 01: 2903 thread 02: 4352 thread 03: 3444 thread 04: 4405 -- DE Index: thread/thr_kern.c =================================================================== RCS file: /opt/FreeBSD/cvs/src/lib/libpthread/thread/thr_kern.c,v retrieving revision 1.116 diff -u -r1.116 thr_kern.c --- thread/thr_kern.c 18 Dec 2004 18:07:37 -0000 1.116 +++ thread/thr_kern.c 20 Feb 2005 15:36:33 -0000 @@ -1465,14 +1465,22 @@ static void kse_check_completed(struct kse *kse) { - struct pthread *thread; + TAILQ_HEAD(, pthread) completeq; + struct pthread *thread, *next; struct kse_thr_mailbox *completed; int sig; if ((completed = kse->k_kcb->kcb_kmbx.km_completed) != NULL) { + TAILQ_INIT(&completeq); kse->k_kcb->kcb_kmbx.km_completed = NULL; while (completed != NULL) { thread = completed->tm_udata; + TAILQ_INSERT_HEAD(&completeq, thread, pqe); + completed = completed->tm_next; + } + for (thread = TAILQ_FIRST(&completeq); thread != NULL; + thread = next) { + next = TAILQ_NEXT(thread, pqe); DBG_MSG("Found completed thread %p, name %s\n", thread, (thread->name == NULL) ? "none" : thread->name); @@ -1505,7 +1513,6 @@ &thread->tcb->tcb_tmbx.tm_syncsig); thread->tcb->tcb_tmbx.tm_syncsig.si_signo = 0; } - completed = completed->tm_next; } } } From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 16:58:51 2005 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 3488C16A4CE; Sun, 20 Feb 2005 16:58:51 +0000 (GMT) Received: from mx.highway.ne.jp (pip8.usen.ad.jp [61.122.117.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A4B43D48; Sun, 20 Feb 2005 16:58:49 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.195.104.17] (helo=[192.168.11.16]) by pop11.isp.us-com.jp with esmtp (Mail 4.20) id 1D2uPp-0008Rc-OE; Mon, 21 Feb 2005 01:58:41 +0900 Message-ID: <4218C19F.8000900@highway.ne.jp> Date: Mon, 21 Feb 2005 01:58:07 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: thread accounting in 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: Sun, 20 Feb 2005 16:58:51 -0000 Daniel Eischen wrote: >I don't get much of a difference with and without patch at >end. Depending on what your threads are blocking on, I >think it can be random. > > with patch > ---------- > thread 00: 4716 > thread 01: 4307 > thread 02: 3631 > thread 03: 3698 > thread 04: 3455 > > without patch > ------------- > thread 00: 4289 > thread 01: 2903 > thread 02: 4352 > thread 03: 3444 > thread 04: 4405 > > > I get a worse result with you patch. -------------------- thread 00: 109322 thread 01: 1130 thread 02: 1129 thread 03: 1105 thread 04: 1155 -------------------- -------------------- Kazuaki Oda From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 23:08:41 2005 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 015CE16A4CE for ; Sun, 20 Feb 2005 23:08:41 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EE243D39 for ; Sun, 20 Feb 2005 23:08:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0B2235136F; Sun, 20 Feb 2005 15:08:40 -0800 (PST) Date: Sun, 20 Feb 2005 15:08:39 -0800 From: Kris Kennaway To: threads@FreeBSD.org Message-ID: <20050220230839.GA12446@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Fatal error 'thread in syncq when it shouldn't be.' 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, 20 Feb 2005 23:08:41 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I often get this error while building mono-related packages on SMP machines (mono, gtk-sharp, etc) on 5.x/6.x. Can someone please take a look? [...] /usr/local/bin/mcs /unsafe /out:vte-sharp.dll /target:library /r:../glib/glib-sharp.dll /r:../pango/pango-sharp.dll /r:../atk/atk-sharp.dll /r:../gdk/gdk-sharp.dll /r:../gtk/gtk-sharp.dll AssemblyInfo.cs generated/*.cs Fatal error 'thread in syncq when it shouldn't be.' at line 1743 in file /c/portbuild.local/i386/5/src/lib/libpthread/thread/thr_mutex.c (errno = 4) Abort trap (core dumped) Kris --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCGRh3Wry0BWjoQKURArFOAJ9AEf16D33mKcrRD9RrSY70rF+geQCg+Thc VAd1so3OJ5VaeEzMo6FJM2I= =VmmL -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-threads@FreeBSD.ORG Sun Feb 20 23:35:46 2005 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 67A3A16A4CE; Sun, 20 Feb 2005 23:35:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F9243D41; Sun, 20 Feb 2005 23:35:46 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1KNZiZQ011988; Sun, 20 Feb 2005 23:35:45 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42191F80.9030207@freebsd.org> Date: Mon, 21 Feb 2005 07:38:40 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: libpthread vs libthread, simply mysql benchmark (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: Sun, 20 Feb 2005 23:35:46 -0000 May I import the library into tree ? I remembered that someone said if it is not in cvs tree, few of people will try it. if people tried it, and find it is not valuable, I can remove it from tree. David Xu Robert Watson wrote: >FYI. > >Robert N M Watson > >---------- Forwarded message ---------- >Date: Sat, 19 Feb 2005 13:16:06 +0000 (GMT) >From: Robert Watson >To: performance@FreeBSD.org >Subject: libpthread vs libthread, simply mysql benchmark > > >In case it's of interest -- I occasionally run MySQL "supersmack" >benchmarks at work on a dual Xeon box there. I ran the select benchmark >on the box a few minutes ago, comparing libpthread and David Xu's new >libthread on the box, and the results are pleasing: > >x 6-SMP-HTT-libpthread >+ 6-SMP-HTT-libthread >+--------------------------------------------------------------------------+ >| x + | >| x ++ | >| xxx +++ | >|xxxxx +++ +| >| |MA| |A| | >+--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev >x 10 8300.25 8442.54 8379.03 8381.652 39.682672 >+ 10 10510.35 10646.98 10547.59 10551.599 39.893907 >Difference at 95.0% confidence > 2169.95 +/- 37.385 > 25.8893% +/- 0.446034% > (Student's t, pooled s = 39.7884) > >In other words, a clear (and healthy) 26% performance improvement on this >simple benchmark. I don't currently have other numbers to compare >against, such as linuxthreads, etc. > >This is a 2.4GHz box with 1gb of memory running MySQL 4.0.23a. Typically, >I get better performance without hyper-threading turned on, but I can't >get into the BIOS of the box remotely so couldn't turn it off properly. I >used the latest 6.x SMP kernel combined with the libthread drop from >David's perforce branch. You can find a URL to his more recent code drops >in the recent threads on freebsd-threads. > >FYI, here's a brief history of HTT performance over the past year as 5.x >and 6.x matured: > >Version Transactions/sec >20040515-UP-4BSD 4862 >20040515-SMP-4BSD 4620 >20040515-SMP-ADMTX-4BSD 4846 > >20040615-UP-4BSD 4899 >20040616-SMP-4BSD 4941 >20040616-SMP-ADMTX-4BSD 4979 > >20040616-netperf-UP-giant-4BSD 4907 >20040616-netperf-UP-mpsafe-4BSD 4939 >20040616-netperf-SMP-giant-4BSD 4587 >20040616-netperf-SMP-mpsafe-4BSD 4609 >20040616-netperf-SMP-ADMTX-giant-4BSD 4662 >20040616-netperf-SMP-ADMTX-mpsafe-4BSD 6425 > >20040713-netperf-SMP-ADMTX-mpsafe-4BSD 7063 > >20040717-netperf-SMP-ADMTX-mpsafe-4BSD 7118 > >As of today, I get about 8400tps with HTT turned on, probably a bit >betterwith it turned off. By combining various factors we've introduced >in the last couple of years, such as MPSAFE network stack, scheduling >improvements, threading improvements, mutex changes, etc, we've improved >performance on mysql by over 100% on SMP, going from quite sub-par >performance in the depths of 5.x development (when all the infrastructure >changes were going in but no optimizations) to quite healthy in 6.x, >especially with the new threading library. > >Robert N M Watson > >_______________________________________________ >freebsd-performance@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-performance >To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > > > From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 01:02:01 2005 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 CD8E616A4CE; Mon, 21 Feb 2005 01:02:01 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF7E43D1D; Mon, 21 Feb 2005 01:02:01 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-120-130-255.dsl.snfc21.pacbell.net [68.120.130.255])j1L11xuq067496; Sun, 20 Feb 2005 20:02:00 -0500 Message-ID: <42193303.2090500@elischer.org> Date: Sun, 20 Feb 2005 17:01:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu References: <4217DD2A.4030603@freebsd.org> In-Reply-To: <4217DD2A.4030603@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: thread accounting in 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, 21 Feb 2005 01:02:01 -0000 David Xu wrote: > Daniel Eischen wrote: > >> ... >> >> since it will be the only thread in the queue. If N threads >> complete (assuming they are all at the same priority) then >> the first thread pulled from the completed list will be >> run first since it will be the first thread added to the >> run queue. >> >> >> > note that kernel adds completed thread in reversed order. I guess we could fix that easily with a tail pointer. > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 02:38:49 2005 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 76B9C16A4CE; Mon, 21 Feb 2005 02:38:49 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D39543D55; Mon, 21 Feb 2005 02:38:49 +0000 (GMT) (envelope-from davidxu@t2t2.com) Received: from t2t2.com (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1L2chJx036557; Mon, 21 Feb 2005 02:38:47 GMT (envelope-from davidxu@t2t2.com) Message-ID: <42194993.4060202@t2t2.com> Date: Mon, 21 Feb 2005 10:38:11 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <4217DD2A.4030603@freebsd.org> <42193303.2090500@elischer.org> In-Reply-To: <42193303.2090500@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org cc: David Xu Subject: Re: thread accounting in 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, 21 Feb 2005 02:38:49 -0000 Julian Elischer wrote: > David Xu wrote: > >> Daniel Eischen wrote: >> >>> ... >>> >>> since it will be the only thread in the queue. If N threads >>> complete (assuming they are all at the same priority) then >>> the first thread pulled from the completed list will be >>> run first since it will be the first thread added to the >>> run queue. >>> >>> >>> >> note that kernel adds completed thread in reversed order. > > > I guess we could fix that easily with a tail pointer. This will break binary compatible, userland can workaround it. David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 04:53:28 2005 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 206C816A4CE; Mon, 21 Feb 2005 04:53:28 +0000 (GMT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id A164243D2F; Mon, 21 Feb 2005 04:53:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-124-206-88.dsl.snfc21.pacbell.net [68.124.206.88])j1L4rFHb156202; Sun, 20 Feb 2005 23:53:20 -0500 Message-ID: <42196937.3010902@elischer.org> Date: Sun, 20 Feb 2005 20:53:11 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu References: <4217DD2A.4030603@freebsd.org> <42193303.2090500@elischer.org> <42194993.4060202@t2t2.com> In-Reply-To: <42194993.4060202@t2t2.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: threads@freebsd.org cc: David Xu Subject: Re: thread accounting in 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, 21 Feb 2005 04:53:28 -0000 David Xu wrote: > > > Julian Elischer wrote: > >> David Xu wrote: >> >>> Daniel Eischen wrote: >>> >>>> ... >>>> >>>> since it will be the only thread in the queue. If N threads >>>> complete (assuming they are all at the same priority) then >>>> the first thread pulled from the completed list will be >>>> run first since it will be the first thread added to the >>>> run queue. >>>> >>>> >>>> >>> note that kernel adds completed thread in reversed order. >> >> >> >> I guess we could fix that easily with a tail pointer. No, I think that the kernel could queue up "completed" threads on the ksegrp in the reverse order to now by adding them to the end of the list instead of the head. nothing else need know except that function. > > > This will break binary compatible, userland can workaround it. The userland doesn't know the order they completed (except to assume that it is backwards) > > David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 06:00:29 2005 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 8942216A4CF for ; Mon, 21 Feb 2005 06:00:29 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22D7F43D4C for ; Mon, 21 Feb 2005 06:00:29 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1L60RoF022820; Mon, 21 Feb 2005 01:00:27 -0500 (EST) Date: Mon, 21 Feb 2005 01:00:27 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kris Kennaway In-Reply-To: <20050220230839.GA12446@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: Fatal error 'thread in syncq when it shouldn't be.' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 06:00:29 -0000 On Sun, 20 Feb 2005, Kris Kennaway wrote: > I often get this error while building mono-related packages on SMP > machines (mono, gtk-sharp, etc) on 5.x/6.x. Can someone please take a > look? > > [...] /usr/local/bin/mcs /unsafe /out:vte-sharp.dll /target:library > /r:../glib/glib-sharp.dll /r:../pango/pango-sharp.dll /r:../atk/atk-sharp.dll > /r:../gdk/gdk-sharp.dll /r:../gtk/gtk-sharp.dll AssemblyInfo.cs generated/*.cs > Fatal error 'thread in syncq when it shouldn't be.' at line 1743 in file > /c/portbuild.local/i386/5/src/lib/libpthread/thread/thr_mutex.c (errno = 4) > Abort trap (core dumped) How recent is your system? There is no such assertion at line 1743 in thr_mutex.c. The only assertion is at or around line 1802. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 06:02:41 2005 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 E487C16A4CE; Mon, 21 Feb 2005 06:02:41 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B96143D62; Mon, 21 Feb 2005 06:02:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1L62eNF025256; Mon, 21 Feb 2005 01:02:40 -0500 (EST) Date: Mon, 21 Feb 2005 01:02:40 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <42191F80.9030207@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: Robert Watson Subject: Re: libpthread vs libthread, simply mysql benchmark (fwd) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 06:02:42 -0000 On Mon, 21 Feb 2005, David Xu wrote: > May I import the library into tree ? I remembered that someone said if > it is not > in cvs tree, few of people will try it. if people tried it, and find it > is not valuable, > I can remove it from tree. I would rather have you incorporate it into libpthread if you can add the SCHED_* and priority mutex support. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 06:04:44 2005 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 D0EA516A4CE; Mon, 21 Feb 2005 06:04:44 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 544B343D48; Mon, 21 Feb 2005 06:04:44 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1L64g5P026584; Mon, 21 Feb 2005 01:04:42 -0500 (EST) Date: Mon, 21 Feb 2005 01:04:42 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <42193303.2090500@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: David Xu Subject: Re: thread accounting in libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 06:04:45 -0000 On Sun, 20 Feb 2005, Julian Elischer wrote: > David Xu wrote: > > Daniel Eischen wrote: > > > >> ... > >> > >> since it will be the only thread in the queue. If N threads > >> complete (assuming they are all at the same priority) then > >> the first thread pulled from the completed list will be > >> run first since it will be the first thread added to the > >> run queue. > >> > >> > >> > > note that kernel adds completed thread in reversed order. > > I guess we could fix that easily with a tail pointer. I don't know that it matters much. With the work-around I posted, it made matters even worse for the test case. I'm not against you changing the ordering in the kenel if you think that is best. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 06:05:19 2005 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 39AF216A4CE; Mon, 21 Feb 2005 06:05:19 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E95C643D31; Mon, 21 Feb 2005 06:05:18 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F26975129C; Sun, 20 Feb 2005 22:05:17 -0800 (PST) Date: Sun, 20 Feb 2005 22:05:17 -0800 From: Kris Kennaway To: Daniel Eischen Message-ID: <20050221060517.GA24972@xor.obsecurity.org> References: <20050220230839.GA12446@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: threads@freebsd.org cc: Kris Kennaway Subject: Re: Fatal error 'thread in syncq when it shouldn't be.' 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, 21 Feb 2005 06:05:19 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 21, 2005 at 01:00:27AM -0500, Daniel Eischen wrote: > On Sun, 20 Feb 2005, Kris Kennaway wrote: >=20 > > I often get this error while building mono-related packages on SMP > > machines (mono, gtk-sharp, etc) on 5.x/6.x. Can someone please take a > > look? > > > > [...] /usr/local/bin/mcs /unsafe /out:vte-sharp.dll /target:library > > /r:../glib/glib-sharp.dll /r:../pango/pango-sharp.dll /r:../atk/atk-sha= rp.dll > > /r:../gdk/gdk-sharp.dll /r:../gtk/gtk-sharp.dll AssemblyInfo.cs generat= ed/*.cs > > Fatal error 'thread in syncq when it shouldn't be.' at line 1743 in file > > /c/portbuild.local/i386/5/src/lib/libpthread/thread/thr_mutex.c (errno = =3D 4) > > Abort trap (core dumped) >=20 > How recent is your system? There is no such assertion at line 1743 in > thr_mutex.c. The only assertion is at or around line 1802. This particular environment hasn't been rebuilt since Dec 21, but I think I've see it elsewhere on more recent environments. I'll rebuild it though and try to obtain another error. Kris --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCGXodWry0BWjoQKURArxZAKCkkdZ8YxUuHOQKgcVYV/7XHlGgbwCeJXZN HSdvEIAwvgSdrjoieUkU3iY= =Ba7R -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 07:44:50 2005 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 4387D16A4CE; Mon, 21 Feb 2005 07:44:50 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D12F43D3F; Mon, 21 Feb 2005 07:44:50 +0000 (GMT) (envelope-from davidxu@t2t2.com) Received: from t2t2.com (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1L7iejh009849; Mon, 21 Feb 2005 07:44:48 GMT (envelope-from davidxu@t2t2.com) Message-ID: <42199148.8040104@t2t2.com> Date: Mon, 21 Feb 2005 15:44:08 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org cc: Robert Watson cc: David Xu Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 07:44:50 -0000 There are lots of differences, I don't think they are the same thing. Although it was derived from libpthread, now it is a new library, I rewrote most part of code. Daniel Eischen wrote: > On Mon, 21 Feb 2005, David Xu wrote: > > >>May I import the library into tree ? I remembered that someone said if >>it is not >>in cvs tree, few of people will try it. if people tried it, and find it >>is not valuable, >>I can remove it from tree. > > > I would rather have you incorporate it into libpthread if you can > add the SCHED_* and priority mutex support. > From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 10:22:20 2005 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 5CC2416A4CE; Mon, 21 Feb 2005 10:22:20 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDA6C43D2F; Mon, 21 Feb 2005 10:22:19 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 43D2F28C719; Mon, 21 Feb 2005 11:22:17 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 50785407C; Mon, 21 Feb 2005 11:21:37 +0100 (CET) Date: Mon, 21 Feb 2005 11:21:37 +0100 From: Jeremie Le Hen To: David Xu Message-ID: <20050221102137.GF1437@obiwan.tataz.chchile.org> References: <42199148.8040104@t2t2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42199148.8040104@t2t2.com> User-Agent: Mutt/1.5.7i cc: Daniel Eischen cc: threads@freebsd.org cc: Robert Watson cc: David Xu Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 10:22:20 -0000 > There are lots of differences, I don't think they are the same > thing. Although it was derived from libpthread, now it is a new > library, I rewrote most part of code. Ok guys, please excuse my ignorance, but I'm wondering what threading scheme this new library could bring. I know we already have libc_r (M-1), libthr (1-1) and libkse AKA libpthread (M-N). Thinking and thinking again about it doesn't help me. I checked the FreeBSD SMP project page (which has many thins to be tagged from "In progress" to "Done"), but I saw no answer. Thanks. Regards, -- Jeremie Le Hen jeremie at le-hen dot org From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 10:34:26 2005 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 226A416A4CE; Mon, 21 Feb 2005 10:34:26 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F6A43D48; Mon, 21 Feb 2005 10:34:25 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 2E42646B04; Mon, 21 Feb 2005 05:34:23 -0500 (EST) Date: Mon, 21 Feb 2005 10:32:48 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: <42199148.8040104@t2t2.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: threads@freebsd.org cc: David Xu Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 10:34:26 -0000 On Mon, 21 Feb 2005, David Xu wrote: > There are lots of differences, I don't think they are the same thing. > Although it was derived from libpthread, now it is a new library, I > rewrote most part of code. I'm thinking he best place to import it is as a replacement for libthr, since that's the closest architecturally (libthr was also 1:1, synchronization based on umtx, etc). However, we should ping jeff and mtm to make sure they don't object. Another reason not to drop it over libpthread is that it keeps libpthread around for direct comparison (performance, etc), and also means that the production thread library from 5.x is still in 6.x, so gives a better path for testing and merging of fixes. Robert N M Watson > > Daniel Eischen wrote: > > On Mon, 21 Feb 2005, David Xu wrote: > > > > > >>May I import the library into tree ? I remembered that someone said if > >>it is not > >>in cvs tree, few of people will try it. if people tried it, and find it > >>is not valuable, > >>I can remove it from tree. > > > > > > I would rather have you incorporate it into libpthread if you can > > add the SCHED_* and priority mutex support. > > > > From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 11:01:56 2005 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 937BB16A4CE for ; Mon, 21 Feb 2005 11:01:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71E1D43D64 for ; Mon, 21 Feb 2005 11:01:56 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1LB1uKo034416 for ; Mon, 21 Feb 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1LB1sJ2034410 for freebsd-threads@freebsd.org; Mon, 21 Feb 2005 11:01:54 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Feb 2005 11:01:54 GMT Message-Id: <200502211101.j1LB1sJ2034410@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 11:01:56 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc o [2003/05/08] threads/51949threads thread in accept cannot be cancelled s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/11/25] threads/74370threads Cannot get lwp 0 registers in gdb o [2004/12/08] threads/74856threads dig/host broken w/ libthr o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/04] threads/75795threads applications linked with -lc_r can't clos o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function 25 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/01/29] threads/76821threads Add access to gdb unique thread id o [2005/02/01] threads/76938threads include/unistd.h: ttyname_r prototype mis 12 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 11:23:56 2005 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 0E7D416A4CE; Mon, 21 Feb 2005 11:23:56 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D06B943D1F; Mon, 21 Feb 2005 11:23:55 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6608B46B1C; Mon, 21 Feb 2005 06:23:55 -0500 (EST) Date: Mon, 21 Feb 2005 11:22:20 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: threads@freebsd.org cc: David Xu Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 11:23:56 -0000 On Mon, 21 Feb 2005, Robert Watson wrote: > On Mon, 21 Feb 2005, David Xu wrote: > > > There are lots of differences, I don't think they are the same thing. > > Although it was derived from libpthread, now it is a new library, I > > rewrote most part of code. > > I'm thinking he best place to import it is as a replacement for libthr, > since that's the closest architecturally (libthr was also 1:1, > synchronization based on umtx, etc). However, we should ping jeff and > mtm to make sure they don't object. > > Another reason not to drop it over libpthread is that it keeps > libpthread around for direct comparison (performance, etc), and also > means that the production thread library from 5.x is still in 6.x, so > gives a better path for testing and merging of fixes. BTW, have you had a chance to do gdb debugging support for this as yet? Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 12:51:23 2005 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 A06F816A4CE; Mon, 21 Feb 2005 12:51:23 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 312EC43D49; Mon, 21 Feb 2005 12:51:23 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1LCpD52027433; Mon, 21 Feb 2005 07:51:19 -0500 (EST) Date: Mon, 21 Feb 2005 07:51:13 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <42199148.8040104@t2t2.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: Robert Watson cc: David Xu Subject: Re: libpthread vs libthread, simply mysql benchmark (fwd) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 12:51:23 -0000 On Mon, 21 Feb 2005, David Xu wrote: > There are lots of differences, I don't think they are the same > thing. Although it was derived from libpthread, now it is a new > library, I rewrote most part of code. I know - as long as it has the same ability I don't care. -- DE From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 13:04:19 2005 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 0661416A4CE; Mon, 21 Feb 2005 13:04:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE9B343D46; Mon, 21 Feb 2005 13:04:18 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1LD4Ccm051206; Mon, 21 Feb 2005 13:04:14 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4219DC49.5020401@freebsd.org> Date: Mon, 21 Feb 2005 21:04:09 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: David Xu cc: Daniel Eischen cc: threads@freebsd.org Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 13:04:19 -0000 Robert Watson wrote: >BTW, have you had a chance to do gdb debugging support for this as yet? > > > Yes, it is in my perforce tree, check out libthread_db and try. >Robert N M Watson > > > > > From owner-freebsd-threads@FreeBSD.ORG Mon Feb 21 13:09:50 2005 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 08D3916A4CE; Mon, 21 Feb 2005 13:09:50 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF62F43D45; Mon, 21 Feb 2005 13:09:49 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1LD9hqa055287; Mon, 21 Feb 2005 13:09:46 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4219DD95.6020109@freebsd.org> Date: Mon, 21 Feb 2005 21:09:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <4219DC49.5020401@freebsd.org> In-Reply-To: <4219DC49.5020401@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: David Xu cc: Daniel Eischen cc: Robert Watson cc: threads@freebsd.org Subject: Re: libpthread vs libthread, simply mysql benchmark (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, 21 Feb 2005 13:09:50 -0000 FYI, you'd better update libthread at same time, as I updated debug symbols yesterday. David Xu wrote: > Robert Watson wrote: > >> BTW, have you had a chance to do gdb debugging support for this as yet? >> >> > Yes, it is in my perforce tree, check out libthread_db and try. > >> Robert N M Watson >> >> >> >> >> > > From owner-freebsd-threads@FreeBSD.ORG Tue Feb 22 20:00:41 2005 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CAD016A4DA for ; Tue, 22 Feb 2005 20:00:41 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAE4E43D31 for ; Tue, 22 Feb 2005 20:00:40 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1MK0eTM033115 for ; Tue, 22 Feb 2005 20:00:40 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1MK0e46033113; Tue, 22 Feb 2005 20:00:40 GMT (envelope-from gnats) Date: Tue, 22 Feb 2005 20:00:40 GMT Message-Id: <200502222000.j1MK0e46033113@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Dong Xuezhang-A19583 Subject: Re: threads/72953: fork() unblocks blocked signals w/o PTHREAD_SC OPE_SYSTEM X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dong Xuezhang-A19583 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:00:41 -0000 The following reply was made to PR threads/72953; it has been noted by GNATS. From: Dong Xuezhang-A19583 To: freebsd-gnats-submit@FreeBSD.org, marka@daemon.lab.isc.org Cc: Subject: Re: threads/72953: fork() unblocks blocked signals w/o PTHREAD_SC OPE_SYSTEM Date: Tue, 22 Feb 2005 12:57:15 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C51918.B4EDF491 Content-Type: text/plain This is not a bug. If you insert a sleep call before the line of kill singal, you will get consistent behavior of "singal 15". Actually fork() donot copy the properties of singal mask, so it never been a case of singal 15 been blocked. The reason of sometime the singal donot get print out is because of race condition in two thread. The reason it "works" at Linux is because of a BUG in Linux which donot deliver the singal to all threads. I modify the code to demostrate two thread case and two process case. You will notice that twothread.c will have different behavior in Linux vs. Freebsd. ======= twothread.c============== #include #include #include #include #include #include #include sigset_t signal_mask; static void * waiter(void *arg) { int result; int sig; result = sigwait(&signal_mask, &sig); if (result != 0) fprintf(stdout, "child thread sigwait: %\n", strerror(result)); else fprintf(stdout, "child thread signal %d\n", sig); fflush(stdout); return (NULL); } int main(int argc, char **argv) { pthread_t id; pthread_attr_t attr; int result; int scope = 0; if (argc > 1) { if (strcmp(argv[1], "system") == 0) scope = 1; } sigemptyset (&signal_mask); sigaddset (&signal_mask, SIGTERM); result = sigprocmask(SIG_BLOCK, &signal_mask, NULL); if (result != 0) fprintf(stdout, "pthread_sigmask: %\n", strerror(result)); else fprintf(stdout, "pthread_sigmask: OK\n"); fflush(stdout); result = pthread_attr_init(&attr); if (result != 0) fprintf(stdout, "pthread_attr_init: %\n", strerror(result)); else fprintf(stdout, "pthread_attr_init: OK\n"); fflush(stdout); if (scope) { result = pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM); if (result != 0) fprintf(stdout, "pthread_attr_setscope: %\n", strerror(result)); else fprintf(stdout, "pthread_attr_setscope: OK\n"); } else fprintf(stdout, "default scope\n"); fflush(stdout); result = pthread_create (&id, &attr, waiter, NULL); if (result != 0) fprintf(stdout, "pthread_create: %\n", strerror(result)); else fprintf(stdout, "pthread_create: OK\n"); fflush(stdout); sleep(1); if (kill(getpid(), SIGTERM) == -1) perror("kill"); else fprintf(stdout, "kill: OK\n"); fflush(stdout); result = pthread_join(id, NULL); if (result != 0) fprintf(stdout, "pthread_join: %\n", strerror(result)); else fprintf(stdout, "pthread_join: OK\n"); fflush(stdout); sleep(1); return(0); } ======= twoprocess.c============== #include #include #include #include #include #include #include sigset_t signal_mask; int childpid; void dofork() { int result; int sig; childpid = fork(); switch (childpid) { case 0: result = sigwait(&signal_mask, &sig); if (result != 0) fprintf(stdout, "sigwait: %\n", strerror(result)); else fprintf(stdout, "signal %d\n", sig); fflush(stdout); _exit(0); case -1: // some error _exit(1); default: // parent process fprintf(stdout, "fork, in parent process\n"); fflush(stdout); break; } } int main(int argc, char **argv) { pthread_t id; pthread_attr_t attr; int result; sigemptyset (&signal_mask); sigaddset (&signal_mask, SIGTERM); result = sigprocmask(SIG_BLOCK, &signal_mask, NULL); if (result != 0) fprintf(stdout, "pthread_sigmask: %\n", strerror(result)); else fprintf(stdout, "pthread_sigmask: OK\n"); fflush(stdout); dofork(); sleep(1); if (kill(childpid, SIGTERM) == -1) perror("kill"); else fprintf(stdout, "kill: OK\n"); fflush(stdout); return(0); } ------_=_NextPart_001_01C51918.B4EDF491 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTEiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz00OTAwNTQ4MTktMjIwMjIwMDU+VGhpcyBpcyBub3QgYSBidWcuIA0KSWYgeW91IGluc2VydCBh IHNsZWVwIGNhbGwgYmVmb3JlIHRoZSBsaW5lIG9mIGtpbGwgc2luZ2FsLCB5b3Ugd2lsbCBnZXQg DQpjb25zaXN0ZW50IGJlaGF2aW9yIG9mICJzaW5nYWwgMTUiLjwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MDA1NDgxOS0yMjAy MjAwNT5BY3R1YWxseSBmb3JrKCkgDQpkb25vdCBjb3B5IHRoZSBwcm9wZXJ0aWVzIG9mIHNpbmdh bCBtYXNrLCBzbyBpdCBuZXZlciBiZWVuIGEgY2FzZSBvZiBzaW5nYWwgMTUgDQpiZWVuIGJsb2Nr ZWQuIFRoZSByZWFzb24gb2Ygc29tZXRpbWUgdGhlIHNpbmdhbCBkb25vdCBnZXQgcHJpbnQgb3V0 IGlzIGJlY2F1c2UgDQpvZiByYWNlIGNvbmRpdGlvbiBpbiB0d28gdGhyZWFkLiBUaGUgcmVhc29u IGl0ICJ3b3JrcyIgYXQgTGludXggaXMgYmVjYXVzZSBvZiBhIA0KQlVHIGluIExpbnV4IHdoaWNo IGRvbm90IGRlbGl2ZXIgdGhlIHNpbmdhbCB0byBhbGwgdGhyZWFkcy48L1NQQU4+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTQ5MDA1NDgx OS0yMjAyMjAwNT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiBjbGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+SSBtb2RpZnkgdGhlIGNv ZGUgdG8gDQpkZW1vc3RyYXRlIHR3byB0aHJlYWQgY2FzZSBhbmQgdHdvIHByb2Nlc3MgY2FzZS4g WW91IHdpbGwgbm90aWNlIHRoYXQgDQp0d290aHJlYWQuYyB3aWxsIGhhdmUgZGlmZmVyZW50IGJl aGF2aW9yIGluIExpbnV4IHZzLiANCkZyZWVic2QuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1Pj09PT09PT0gDQp0d290aHJlYWQuYz09PT09 PT09PT09PT09PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PFNQQU4gY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1PiNpbmNsdWRlIA0KJmx0O3B0aHJlYWQu aCZndDs8QlI+I2luY2x1ZGUgJmx0O3VuaXN0ZC5oJmd0OzxCUj4jaW5jbHVkZSANCiZsdDtzdGRp by5oJmd0OzxCUj4jaW5jbHVkZSAmbHQ7c3lzL3R5cGVzLmgmZ3Q7PEJSPiNpbmNsdWRlIA0KJmx0 O3N5cy93YWl0LmgmZ3Q7PEJSPiNpbmNsdWRlICZsdDtzaWduYWwuaCZndDs8QlI+I2luY2x1ZGUg DQombHQ7c3RkbGliLmgmZ3Q7PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj48U1BBTiBjbGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+c2lnc2V0X3QgDQpzaWduYWxfbWFz azs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNz PTQ5MDA1NDgxOS0yMjAyMjAwNT5zdGF0aWMgdm9pZCANCio8QlI+d2FpdGVyKHZvaWQgKmFyZykg ezxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50IA0KcmVz dWx0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50IA0K c2lnOzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpj bGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJlc3VsdCA9IA0Kc2lnd2FpdCgmYW1wO3NpZ25hbF9tYXNrLCANCiZhbXA7c2ln KTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChyZXN1 bHQgIT0gDQowKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpmcHJpbnRm KHN0ZG91dCwgImNoaWxkIHRocmVhZCBzaWd3YWl0OiAlXG4iLCANCnN0cmVycm9yKHJlc3VsdCkp OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQplbHNlPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAiY2hp bGQgdGhyZWFkIHNpZ25hbCAlZFxuIiwgDQpzaWcpOzxCUj4mbmJzcDtmZmx1c2goc3Rkb3V0KTs8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcmV0dXJuIChO VUxMKTs8QlI+fTwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1PmludDxCUj5tYWluKGludCANCmFyZ2MsIGNoYXIg Kiphcmd2KSB7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw dGhyZWFkX3QgDQppZDs8QlI+Jm5ic3A7cHRocmVhZF9hdHRyX3QgYXR0cjs8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaW50IHJlc3VsdDs8QlI+Jm5ic3A7 aW50IHNjb3BlID0gMDs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00OTAwNTQ4MTktMjIwMjIw MDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChhcmdjIA0K Jmd0OyAxKSANCns8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaWYgKHN0 cmNtcChhcmd2WzFdLCAic3lzdGVtIikgPT0gDQowKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQpzY29wZSA9IDE7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1PiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaWdlbXB0eXNldCANCigmYW1w O3NpZ25hbF9tYXNrKTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNpZ2FkZHNldCANCigmYW1wO3NpZ25hbF9tYXNrLCBTSUdURVJNKTs8L1NQQU4+PC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gDQpjbGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3VsdCA9IA0Kc2lncHJvY21hc2soU0lHX0JMT0NLLCAmYW1w O3NpZ25hbF9tYXNrLCANCk5VTEwpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaWYgKHJlc3VsdCAhPSANCjApPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAicHRocmVhZF9zaWdtYXNrOiAlXG4iLCANCnN0 cmVycm9yKHJlc3VsdCkpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQplbHNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmlu dGYoc3Rkb3V0LCAicHRocmVhZF9zaWdtYXNrOiANCk9LXG4iKTs8QlI+Jm5ic3A7ZmZsdXNoKHN0 ZG91dCk7PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MDA1NDgxOS0yMjAyMjAwNT4mbmJzcDty ZXN1bHQgPSANCnB0aHJlYWRfYXR0cl9pbml0KCZhbXA7YXR0cik7PEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiANCihyZXN1bHQgIT0gDQowKTxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpmcHJpbnRmKHN0ZG91dCwgInB0aHJlYWRf YXR0cl9pbml0OiAlXG4iLCANCnN0cmVycm9yKHJlc3VsdCkpOzxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQplbHNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAicHRocmVhZF9hdHRyX2luaXQ6IA0KT0tc biIpOzxCUj4mbmJzcDtmZmx1c2goc3Rkb3V0KTs8QlI+Jm5ic3A7PEJSPiZuYnNwO2lmIChzY29w ZSkgDQp7PEJSPiZuYnNwOyZuYnNwO3Jlc3VsdCA9IHB0aHJlYWRfYXR0cl9zZXRzY29wZSgmYW1w O2F0dHIsIA0KUFRIUkVBRF9TQ09QRV9TWVNURU0pOzxCUj4mbmJzcDsmbmJzcDtpZiAocmVzdWx0 ICE9IA0KMCk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ZnByaW50ZihzdGRvdXQsICJwdGhyZWFkX2F0 dHJfc2V0c2NvcGU6IA0KJVxuIiw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3RyZXJyb3Io cmVzdWx0KSk7PEJSPiZuYnNwOyZuYnNwO2Vsc2U8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ZnByaW50 ZihzdGRvdXQsIA0KInB0aHJlYWRfYXR0cl9zZXRzY29wZTogT0tcbiIpOzxCUj4mbmJzcDt9IGVs c2U8QlI+Jm5ic3A7Jm5ic3A7ZnByaW50ZihzdGRvdXQsIA0KImRlZmF1bHQgc2NvcGVcbiIpOzxC Uj4mbmJzcDtmZmx1c2goc3Rkb3V0KTs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00OTAwNTQ4 MTktMjIwMjIwMDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl c3VsdCA9IA0KcHRocmVhZF9jcmVhdGUgKCZhbXA7aWQsICZhbXA7YXR0ciwgd2FpdGVyLCANCk5V TEwpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYgKHJl c3VsdCAhPSANCjApPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmlu dGYoc3Rkb3V0LCAicHRocmVhZF9jcmVhdGU6ICVcbiIsIA0Kc3RyZXJyb3IocmVzdWx0KSk7PEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmVsc2U8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZnByaW50ZihzdGRvdXQsICJwdGhyZWFk X2NyZWF0ZTogDQpPS1xuIik7PEJSPiZuYnNwO2ZmbHVzaChzdGRvdXQpOzwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCmNsYXNzPTQ5MDA1NDgxOS0yMjAyMjAwNT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpzbGVlcCgxKTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChraWxsKGdldHBpZCgpLCANClNJR1RFUk0pID09IA0KLTEp PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnBlcnJvcigia2lsbCIpOzxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQplbHNlPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAia2lsbDog T0tcbiIpOzxCUj4mbmJzcDtmZmx1c2goc3Rkb3V0KTs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFz cz00OTAwNTQ4MTktMjIwMjIwMDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlc3VsdCA9IA0KcHRocmVhZF9qb2luKGlkLCBOVUxMKTs8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChyZXN1bHQgDQohPSANCjApPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAicHRocmVh ZF9qb2luOiAlXG4iLCANCnN0cmVycm9yKHJlc3VsdCkpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQplbHNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAicHRocmVhZF9qb2luOiANCk9LXG4iKTs8QlI+ Jm5ic3A7ZmZsdXNoKHN0ZG91dCk7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCnNsZWVwKDEpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpyZXR1cm4oMCk7PEJSPn08QlI+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1 Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz00OTAwNTQ4MTktMjIw MjIwMDU+PT09PT09PSANCnR3b3Byb2Nlc3MuYz09PT09PT09PT09PT09PC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NDkwMDU0ODE5 LTIyMDIyMDA1PiNpbmNsdWRlIA0KJmx0O3B0aHJlYWQuaCZndDs8QlI+I2luY2x1ZGUgJmx0O3Vu aXN0ZC5oJmd0OzxCUj4jaW5jbHVkZSANCiZsdDtzdGRpby5oJmd0OzxCUj4jaW5jbHVkZSAmbHQ7 c3lzL3R5cGVzLmgmZ3Q7PEJSPiNpbmNsdWRlIA0KJmx0O3N5cy93YWl0LmgmZ3Q7PEJSPiNpbmNs dWRlICZsdDtzaWduYWwuaCZndDs8QlI+I2luY2x1ZGUgDQombHQ7c3RkbGliLmgmZ3Q7PC9TUEFO PjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MDA1NDgxOS0yMjAyMjAwNT5zaWdzZXRfdCANCnNpZ25hbF9t YXNrOzxCUj5pbnQgY2hpbGRwaWQ7PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ5MDA1NDgxOS0y MjAyMjAwNT52b2lkPEJSPmRvZm9yaygpIA0KezxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaW50IA0KcmVzdWx0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50IA0Kc2lnOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hpbGRwaWQgPSANCmZvcmsoKTs8QlI+Jm5ic3A7Jm5ic3A7 IHN3aXRjaCAoY2hpbGRwaWQpIHs8QlI+Jm5ic3A7Jm5ic3A7IGNhc2UgDQowOjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3VsdCA9IA0Kc2lnd2Fp dCgmYW1wO3NpZ25hbF9tYXNrLCANCiZhbXA7c2lnKTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChyZXN1bHQgDQohPSANCjApPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0LCAic2ln d2FpdDogJVxuIiwgDQpzdHJlcnJvcihyZXN1bHQpKTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZWxzZTxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpmcHJpbnRmKHN0ZG91dCwgInNpZ25hbCAlZFxuIiwgc2ln KTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZmZsdXNoKHN0ZG91dCk7PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCl9leGl0KDApOzxCUj4mbmJzcDsmbmJzcDsg Y2FzZSANCi0xOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQovLyBzb21l IGVycm9yPEJSPiZuYnNwOyZuYnNwO19leGl0KDEpOzxCUj4mbmJzcDsmbmJzcDsgDQpkZWZhdWx0 OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQovLyBwYXJlbnQgDQpwcm9j ZXNzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZwcmludGYoc3Rkb3V0 LCAiZm9yaywgaW4gcGFyZW50IA0KcHJvY2Vzc1xuIik7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCmZmbHVzaChzdGRvdXQpOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpicmVhazs8QlI+Jm5ic3A7Jm5ic3A7IH08QlI+fTwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCmNsYXNzPTQ5MDA1NDgxOS0yMjAyMjAwNT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+aW50PEJSPm1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2 KSB7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnB0aHJlYWRfdCBpZDs8QlI+ Jm5ic3A7cHRocmVhZF9hdHRyX3QgYXR0cjs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KaW50IHJlc3VsdDs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00OTAwNTQ4MTktMjIw MjIwMDU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ2VtcHR5c2V0IA0KKCZhbXA7 c2lnbmFsX21hc2spOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnYWRkc2V0 IA0KKCZhbXA7c2lnbmFsX21hc2ssIFNJR1RFUk0pOzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNz PTQ5MDA1NDgxOS0yMjAyMjAwNT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdWx0 ID0gDQpzaWdwcm9jbWFzayhTSUdfQkxPQ0ssICZhbXA7c2lnbmFsX21hc2ssIA0KTlVMTCk7PEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiAocmVzdWx0ICE9IA0KMCk8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZnByaW50ZihzdGRvdXQsICJwdGhyZWFkX3NpZ21h c2s6ICVcbiIsIA0Kc3RyZXJyb3IocmVzdWx0KSk7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCmVsc2U8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZnBy aW50ZihzdGRvdXQsICJwdGhyZWFkX3NpZ21hc2s6IA0KT0tcbiIpOzxCUj4mbmJzcDtmZmx1c2go c3Rkb3V0KTs8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00OTAwNTQ4MTktMjIwMjIwMDU+Jm5i c3A7ZG9mb3JrKCk7PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDkwMDU0ODE5LTIyMDIyMDA1 PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnNsZWVwKDEpOzwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCmNsYXNzPTQ5MDA1NDgxOS0yMjAyMjAwNT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaWYgKGtpbGwoY2hpbGRwaWQsIA0KU0lHVEVSTSkgPT0gDQotMSk8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcGVycm9yKCJraWxsIik7PEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCmVsc2U8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KZnByaW50ZihzdGRvdXQsICJraWxsOiANCk9LXG4iKTs8QlI+Jm5ic3A7ZmZsdXNo KHN0ZG91dCk7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnJldHVybigwKTs8 QlI+fTxCUj48L1NQQU4+PC9GT05UPjwvRElWPjwvRElWPjwvU1BBTj48L0ZPTlQ+PC9CT0RZPjwv SFRNTD4NCg== ------_=_NextPart_001_01C51918.B4EDF491-- From owner-freebsd-threads@FreeBSD.ORG Wed Feb 23 09:31:24 2005 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 3316E16A4CE for ; Wed, 23 Feb 2005 09:31:24 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F004443D1D for ; Wed, 23 Feb 2005 09:31:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 57AAD514DA; Wed, 23 Feb 2005 01:31:23 -0800 (PST) Date: Wed, 23 Feb 2005 01:31:23 -0800 From: Kris Kennaway To: threads@FreeBSD.org Message-ID: <20050223093123.GE66326@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C94crkcyjafcjHxo" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [ports-i386@pointyhat.freebsd.org: gtk-sharp-1.0.4_2 failed on i386 5] 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, 23 Feb 2005 09:31:24 -0000 --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Another error, this time on UP with world built Feb 3. Kris Fatal error 'thread in syncq when it shouldn't be.' at line 1743 in file /a/portbuild/i386/5/src/lib/libpthread/thread/thr_mutex.c (errno = 0) gmake[3]: *** [gnome-hello-world.exe] Abort trap (core dumped) gmake[3]: Leaving directory `/tmp/a/ports/x11-toolkits/gtk-sharp/work/gtk-sharp-1.0.4/sample' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/tmp/a/ports/x11-toolkits/gtk-sharp/work/gtk-sharp-1.0.4/sample' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/a/ports/x11-toolkits/gtk-sharp/work/gtk-sharp-1.0.4' gmake: *** [all] Error 2 *** Error code 2 Stop in /a/ports/x11-toolkits/gtk-sharp. ================================================================ build ended at Wed Feb 23 04:11:22 UTC 2005 --C94crkcyjafcjHxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCHE1qWry0BWjoQKURApUPAKD80xwcZqc3ZWgTFus6U5NxMjLNpgCYgMoX CfvZFsV2z5EvY4yuWQyYWw== =278H -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From owner-freebsd-threads@FreeBSD.ORG Thu Feb 24 06:23:33 2005 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 9F3CE16A4CE for ; Thu, 24 Feb 2005 06:23:33 +0000 (GMT) Received: from smtp200.mail.sc5.yahoo.com (smtp200.mail.sc5.yahoo.com [216.136.130.125]) by mx1.FreeBSD.org (Postfix) with SMTP id 5C99343D1F for ; Thu, 24 Feb 2005 06:23:33 +0000 (GMT) (envelope-from river_robert@yahoo.com.cn) Received: from unknown (HELO ZJZ) (river?robert@219.239.240.220 with login) by smtp200.mail.sc5.yahoo.com with SMTP; 24 Feb 2005 06:23:25 -0000 Date: Thu, 24 Feb 2005 14:23:03 +0800 From: "River" To: "freebsd-threads" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20050224062333.5C99343D1F@mx1.FreeBSD.org> Subject: "sleep" "select" system call not work correctly when linking with multithread libray--FreeBSD 4.5 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: river_robert@yahoo.com.cn List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 06:23:33 -0000 Does anyone know why "sleep" "select" can not work correctly in FreeBSD 4.5 when the system time is set backward for a long time,i.e several hours. The behavior is: sleep or select will be blocked for a long time much longer than expected. Through testing, we found that these two system calls both are OK if linking with the program with standard system libray, but will be blocked when linking with "-pthread" option (I suppose this option will let program link with multithread library) if system time is set backward. Seems like that the implementation of "select" "sleep" in multithread library is reated to system date. It is really wired. This is select testing program-- When time is set backward,the program linked with "-pthread" option did not continue printing anything. But using the program linked with standard library, printing did not affected by system time backward and all is OK. int main(int argc, char *argv[]) { fd_set readset; int result =0; struct timeval interval; interval.tv_sec = 10; interval.tv_usec = 0; for(;;) { result = select(FD_SETSIZE, NULL, NULL,NULL, &interval); switch(result) { case -1: printf(" case -1\n"); continue; case 0: printf("case 0, after select;\n"); continue; case 1: printf("read sth\n"); continue; } } return 0; } This is sleep testing program. Just the same result as select. int main(int argc, char *argv[]) { for(;;) { printf("case 0, before sleep\n"); sleep(5); printf("case 1, after sleep\n"); } return 0; } From owner-freebsd-threads@FreeBSD.ORG Thu Feb 24 15:49:27 2005 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 58F5016A4CE; Thu, 24 Feb 2005 15:49:27 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2109643D2D; Thu, 24 Feb 2005 15:49:25 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 70BB346B35; Thu, 24 Feb 2005 10:49:24 -0500 (EST) Date: Thu, 24 Feb 2005 15:47:40 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: threads@FreeBSD.org, alfred@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: POSIX semaphores and fork() -- when any process exits, they all lose , access 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, 24 Feb 2005 15:49:27 -0000 I was writing some code to exercise POSIX semaphores this morning, and ran into the following issue: If I create a named POSIX semaphore in a process, then fork(), the semaphore appears to be visible to both the parent and child. However, as soon as the child exits, the semaphore disappears from the parent. This seems likely incorrect, although I don't have a copy of the spec in question so couldn't say for sure. It strikes me that the semaphores should either be shared as of exit, with the child and the parent both having references to it, or they should remain only with the parent, and the childs semaphores should be invalidated/corrupted/something. No doubt POSIX has something to say on the topic. Looking at the kernel code, it looks like the semaphore code is aware of process exit() and exec(), but not fork(), which is probably what leads to this behavior. Since POSIX semaphores in the threaded case involve cooperation between the library and kernel to implement, I suspect getting the semantics right may require a bit of work. Does anyone know what the semantics should be, and/or is interested in making our implementation fit those semantics? Thanks, Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Thu Feb 24 20:08:01 2005 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 8F4C416A4CE; Thu, 24 Feb 2005 20:08:01 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1685F43D2F; Thu, 24 Feb 2005 20:08:01 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1OK7xWi027783; Thu, 24 Feb 2005 15:07:59 -0500 (EST) Date: Thu, 24 Feb 2005 15:07:59 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: alfred@freebsd.org Subject: Re: POSIX semaphores and fork() -- when any process exits, they all lose , access X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 20:08:01 -0000 On Thu, 24 Feb 2005, Robert Watson wrote: > > I was writing some code to exercise POSIX semaphores this morning, and ran > into the following issue: > > If I create a named POSIX semaphore in a process, then fork(), the > semaphore appears to be visible to both the parent and child. However, as > soon as the child exits, the semaphore disappears from the parent. This > seems likely incorrect, although I don't have a copy of the spec in > question so couldn't say for sure. http://www.opengroup.org/onlinepubs/009695399/functions/sem_open.html > It strikes me that the semaphores > should either be shared as of exit, with the child and the parent both > having references to it, or they should remain only with the parent, and > the childs semaphores should be invalidated/corrupted/something. No doubt > POSIX has something to say on the topic. > > Looking at the kernel code, it looks like the semaphore code is aware of > process exit() and exec(), but not fork(), which is probably what leads to > this behavior. Since POSIX semaphores in the threaded case involve > cooperation between the library and kernel to implement, I suspect getting > the semantics right may require a bit of work. There shouldn't be anything required in libc or the thread libraries. Shared semaphore lookups are done in the kernel. The thread libraries really only deal with non-named and unshared (*) semaphores. (*) We don't yet support shared semaphores (or mutexes/CVs) 'cause it would cause a big ABI change and probably wreak havoc on ports. This needs to be done, but hopefully only after we decide on symbol versioning vs library version bumping (don't hijack this thread ;-)). > Does anyone know what the semantics should be, and/or is interested in > making our implementation fit those semantics? I'm not familiar with the kernel bits, but I don't think you have to be concerned with the thread libraries. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Feb 25 11:34:26 2005 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 B43C116A4CE; Fri, 25 Feb 2005 11:34:26 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 636D043D31; Fri, 25 Feb 2005 11:34:26 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 89EE046B2C; Fri, 25 Feb 2005 06:34:25 -0500 (EST) Date: Fri, 25 Feb 2005 11:32:39 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: alfred@freebsd.org Subject: Re: POSIX semaphores and fork() -- when any process exits, they all lose , access 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, 25 Feb 2005 11:34:26 -0000 On Thu, 24 Feb 2005, Daniel Eischen wrote: > > If I create a named POSIX semaphore in a process, then fork(), the > > semaphore appears to be visible to both the parent and child. However, as > > soon as the child exits, the semaphore disappears from the parent. This > > seems likely incorrect, although I don't have a copy of the spec in > > question so couldn't say for sure. > > http://www.opengroup.org/onlinepubs/009695399/functions/sem_open.html Hmm. I haven't yet found a reference to fork() semantics for semaphores in the semaphore-related pages. However, a bit of googling turned up the following references: - HIP's Tru64 documentation includes the words: "The semaphore descriptor is inherited across a fork. A parent process can create a semaphore, open it, and fork. The child process does not need to open the semaphore and can close the semaphore if the application is finished with it." So it sounds like the semaphore references for a process basically need to be replicated for the child. One hesitates to guess how this will interact with things like Linux threading. The glibc POSIX semaphores documentation doesn't mention sem_open()/sem_close(), so maybe they only do semaphores in the context of the user thread library, and not inter-process semaphores. Thanks, Robert N M Watson From owner-freebsd-threads@FreeBSD.ORG Fri Feb 25 15:48:14 2005 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 062A616A4CE; Fri, 25 Feb 2005 15:48:14 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE2643D41; Fri, 25 Feb 2005 15:48:13 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1PFmCrj019127; Fri, 25 Feb 2005 10:48:12 -0500 (EST) Date: Fri, 25 Feb 2005 10:48:12 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: alfred@freebsd.org Subject: Re: POSIX semaphores and fork() -- when any process exits, they all lose , access X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 15:48:14 -0000 On Fri, 25 Feb 2005, Robert Watson wrote: > On Thu, 24 Feb 2005, Daniel Eischen wrote: > > > > If I create a named POSIX semaphore in a process, then fork(), the > > > semaphore appears to be visible to both the parent and child. However, as > > > soon as the child exits, the semaphore disappears from the parent. This > > > seems likely incorrect, although I don't have a copy of the spec in > > > question so couldn't say for sure. > > > > http://www.opengroup.org/onlinepubs/009695399/functions/sem_open.html > > Hmm. I haven't yet found a reference to fork() semantics for semaphores > in the semaphore-related pages. However, a bit of googling turned up the > following references: > > - HIP's Tru64 documentation includes the words: > > "The semaphore descriptor is inherited across a fork. A parent process > can create a semaphore, open it, and fork. The child process does not > need to open the semaphore and can close the semaphore if the > application is finished with it." I think this is the desired behaviour. > So it sounds like the semaphore references for a process basically need to > be replicated for the child. One hesitates to guess how this will > interact with things like Linux threading. The glibc POSIX semaphores > documentation doesn't mention sem_open()/sem_close(), so maybe they only > do semaphores in the context of the user thread library, and not > inter-process semaphores. The other thing to remember is that it isn't valid for a threaded process to fork() and have the child process become threaded again. After a fork(), the child process has one thread and the state of its mutexes, CVs, semaphores, etc., are left in whatever their state was from before the fork. The application should use pthread_atfork() handlers if it needs to reuse any of these in the child process. So I don't think there is anything that needs to be done in the thread libraries. -- DE