From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 08:26:23 2006 Return-Path: X-Original-To: threads@freebsd.org 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 C320916A4DD for ; Mon, 10 Jul 2006 08:26:23 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id F406243D55 for ; Mon, 10 Jul 2006 08:26:22 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so591108wri for ; Mon, 10 Jul 2006 01:26:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tNm064l6iHGz4FK2ECSyqJfCMcRoPkSga0ONt7Jtv31ojWkumjjrwFCit7iDi52GmrjFGAYb06l/Xjk+X80hpfwdcA6Jck1zVuuxuhtADXZRR8O7C7cvIEvmyXWweJ6HpkVV4RUnC/qkf+x2VJS+v1Onq9eotKtqcitv91DwaIc= Received: by 10.65.97.17 with SMTP id z17mr4135370qbl; Mon, 10 Jul 2006 01:26:22 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 10 Jul 2006 01:26:21 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 01:26:21 -0700 From: "Kip Macy" To: "Norbert Koch" In-Reply-To: <44AD01C8.2040704@demig.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703101554.Q26325@fledge.watson.org> <200607032020.10993.davidxu@freebsd.org> <44AD01C8.2040704@demig.de> Cc: threads@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 08:26:23 -0000 Is there any reason that exporting the process real time scheduling functionality via the pthread api through libthr would not suffice? -Kip On 7/6/06, Norbert Koch wrote: > > I don't need hard real-time, but would like to be able to use > > FreeBSD for soft real-time. > > me too. > > Norbert Koch > _______________________________________________ > 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 Jul 10 08:26:23 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 CC44216A4DF for ; Mon, 10 Jul 2006 08:26:23 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3ECE43D53 for ; Mon, 10 Jul 2006 08:26:22 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so591109wri for ; Mon, 10 Jul 2006 01:26:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tNm064l6iHGz4FK2ECSyqJfCMcRoPkSga0ONt7Jtv31ojWkumjjrwFCit7iDi52GmrjFGAYb06l/Xjk+X80hpfwdcA6Jck1zVuuxuhtADXZRR8O7C7cvIEvmyXWweJ6HpkVV4RUnC/qkf+x2VJS+v1Onq9eotKtqcitv91DwaIc= Received: by 10.65.97.17 with SMTP id z17mr4135370qbl; Mon, 10 Jul 2006 01:26:22 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 10 Jul 2006 01:26:21 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 01:26:21 -0700 From: "Kip Macy" To: "Norbert Koch" In-Reply-To: <44AD01C8.2040704@demig.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703101554.Q26325@fledge.watson.org> <200607032020.10993.davidxu@freebsd.org> <44AD01C8.2040704@demig.de> Cc: threads@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 08:26:23 -0000 Is there any reason that exporting the process real time scheduling functionality via the pthread api through libthr would not suffice? -Kip On 7/6/06, Norbert Koch wrote: > > I don't need hard real-time, but would like to be able to use > > FreeBSD for soft real-time. > > me too. > > Norbert Koch > _______________________________________________ > 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 Jul 10 09:04:39 2006 Return-Path: X-Original-To: threads@freebsd.org 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 E4FEB16A4E6 for ; Mon, 10 Jul 2006 09:04:38 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F09943D5A for ; Mon, 10 Jul 2006 09:04:36 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so595018wri for ; Mon, 10 Jul 2006 02:04:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jaqeb9FG3mN5cLA/6SuNn8gV/EOOJNOfgc5TU8PRD42LSMDaDBAedI4+FxXHnfU2o9kSBsQN3zb4QZkwWxYH0iGnMSMSJGCMfJrVh3GLn1c/D8AMUMffw17VyRgSIfQpqaYj7wNSV19rFEnk4tXKGHIrLaCK87nbmymH1puZuPU= Received: by 10.65.219.7 with SMTP id w7mr4370487qbq; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 02:04:30 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20060705095450.O64340@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org> Cc: freebsd-threads@freebsd.org, Daniel Eischen , David Xu , threads@freebsd.org, Julian Elischer Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:04:39 -0000 Apart from real time scheduling functionality I have yet to see any real-world technical deficiencies with libthr. I have, however, seen major stability issues with KSE. Network Appliance abandoned FreeBSD as a platform for running their simulator due to frequent hangs caused by signals. More recently, on sun4v, when single stepping csup (or any multi-threaded app for that matter) the debuggee would often get the SIGTRAP and not GDB. When re-starting mysqld for the second or third time the process would become unkillable. These problems are not entirely surprising, KSE makes signal handling *very* complicated. I am disappointed that threads are currently unusable on sun4v with KSE. I would be delighted if sometime in the very near future, one of the following happened: 1. a) Somebody steps up to work on KSE and fixes the signal issues that have long plagued it. John Birrell or Paul Saab can make a T2000 available to any motivated developer. 2. a) David Xu fixes static linking with libthr b) David Xu exports support for real-time scheduling via libthr c) Peter Wemm checks in bike_sched The second seems much more logical, given our desire to become performance competitive with Linux. However, sched_lock is not currently FreeBSD's biggest bottleneck, and thus the first would be acceptable. I would still be pleased at the possibility of sun4v someday being checked into CVS. -Kip On 7/5/06, Robert Watson wrote: > > On Tue, 4 Jul 2006, Julian Elischer wrote: > > > If it come to pass that M:N threads are judged to be "unsuitable" then that > > is a decision that I can live with, but never be let it be said that I > > walled FreeBSD in to only having the option of 1:1 threads. > > Given that I have serious hindsight accuracy problems, I won't even talk about > my foresight issues. :-) I think we shouldn't nail the KSE coffin closed just > yet -- as Peter has already said, it's one thing to do a skunkworks hack of > what might eventually be used, but it's quite another to show that the > perceived benefit maps into real world benefit. I'd like to see that clearly > shown before we do anything drastic. In particular, we need to show that the > benefit is there for more than just a few poorly written benchmarks, but also > for a range of real-world workloads, and that the scheduler simplifications > pay off in terms of both code complexity and our ability to optimize. I also > want to make sure we understand some of the artifacts better: the benefit of > reducing per-process lock contention is significant, and I'm interested in > understanding where on the workload spectrum the benefits of 1:1 outweight the > benefits of M:N a bit better. Is my interpretation that this is M:N providing > better kernel workload management correct, or is it an artifact of scheduler > behavior? And, where future hardware and application trends will push > workload behavior with respect to the optimizations we already have, not to > mention the ones we are considering. > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 09:04:39 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 EF04116A4E8 for ; Mon, 10 Jul 2006 09:04:38 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC1B43D49 for ; Mon, 10 Jul 2006 09:04:36 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so595015wri for ; Mon, 10 Jul 2006 02:04:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jaqeb9FG3mN5cLA/6SuNn8gV/EOOJNOfgc5TU8PRD42LSMDaDBAedI4+FxXHnfU2o9kSBsQN3zb4QZkwWxYH0iGnMSMSJGCMfJrVh3GLn1c/D8AMUMffw17VyRgSIfQpqaYj7wNSV19rFEnk4tXKGHIrLaCK87nbmymH1puZuPU= Received: by 10.65.219.7 with SMTP id w7mr4370487qbq; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 02:04:30 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20060705095450.O64340@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org> Cc: freebsd-threads@freebsd.org, Daniel Eischen , David Xu , threads@freebsd.org, Julian Elischer Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:04:39 -0000 Apart from real time scheduling functionality I have yet to see any real-world technical deficiencies with libthr. I have, however, seen major stability issues with KSE. Network Appliance abandoned FreeBSD as a platform for running their simulator due to frequent hangs caused by signals. More recently, on sun4v, when single stepping csup (or any multi-threaded app for that matter) the debuggee would often get the SIGTRAP and not GDB. When re-starting mysqld for the second or third time the process would become unkillable. These problems are not entirely surprising, KSE makes signal handling *very* complicated. I am disappointed that threads are currently unusable on sun4v with KSE. I would be delighted if sometime in the very near future, one of the following happened: 1. a) Somebody steps up to work on KSE and fixes the signal issues that have long plagued it. John Birrell or Paul Saab can make a T2000 available to any motivated developer. 2. a) David Xu fixes static linking with libthr b) David Xu exports support for real-time scheduling via libthr c) Peter Wemm checks in bike_sched The second seems much more logical, given our desire to become performance competitive with Linux. However, sched_lock is not currently FreeBSD's biggest bottleneck, and thus the first would be acceptable. I would still be pleased at the possibility of sun4v someday being checked into CVS. -Kip On 7/5/06, Robert Watson wrote: > > On Tue, 4 Jul 2006, Julian Elischer wrote: > > > If it come to pass that M:N threads are judged to be "unsuitable" then that > > is a decision that I can live with, but never be let it be said that I > > walled FreeBSD in to only having the option of 1:1 threads. > > Given that I have serious hindsight accuracy problems, I won't even talk about > my foresight issues. :-) I think we shouldn't nail the KSE coffin closed just > yet -- as Peter has already said, it's one thing to do a skunkworks hack of > what might eventually be used, but it's quite another to show that the > perceived benefit maps into real world benefit. I'd like to see that clearly > shown before we do anything drastic. In particular, we need to show that the > benefit is there for more than just a few poorly written benchmarks, but also > for a range of real-world workloads, and that the scheduler simplifications > pay off in terms of both code complexity and our ability to optimize. I also > want to make sure we understand some of the artifacts better: the benefit of > reducing per-process lock contention is significant, and I'm interested in > understanding where on the workload spectrum the benefits of 1:1 outweight the > benefits of M:N a bit better. Is my interpretation that this is M:N providing > better kernel workload management correct, or is it an artifact of scheduler > behavior? And, where future hardware and application trends will push > workload behavior with respect to the optimizations we already have, not to > mention the ones we are considering. > > Robert N M Watson > Computer Laboratory > University of Cambridge > From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 09:23:43 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1E2FC16A4ED; Mon, 10 Jul 2006 09:23:39 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <44B21C9A.3010800@freebsd.org> Date: Mon, 10 Jul 2006 17:23:38 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060519 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kmacy@fsmware.com References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , threads@freebsd.org, Robert Watson , Julian Elischer , freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:23:43 -0000 Kip Macy wrote: > > Apart from real time scheduling functionality I have yet to see any > real-world technical deficiencies with libthr. I have, however, seen > major stability issues with KSE. > > Network Appliance abandoned FreeBSD as a platform for running their > simulator due to frequent hangs caused by signals. More recently, on > sun4v, when single stepping csup (or any multi-threaded app for that > matter) the debuggee would often get the SIGTRAP and not GDB. When > re-starting mysqld for the second or third time the process would > become unkillable. These problems are not entirely surprising, KSE > makes signal handling *very* complicated. I am disappointed that > threads are currently unusable on sun4v with KSE. > > I would be delighted if sometime in the very near future, one of the > following happened: > 1. > a) Somebody steps up to work on KSE and fixes the signal issues that > have long plagued it. John Birrell or Paul Saab can make a T2000 > available to any motivated developer. > > 2. > a) David Xu fixes static linking with libthr I really want somebody who is familiar with weak symbol to help me, since both libthr and libc are using weak symbols (our ABI), according to what my fellows here said, weak symbols are picked up by linker randomly, so how to fix it? I had dicussed this issue with dan, but never got a satisfied answer. > b) David Xu exports support for real-time scheduling via libthr This can be implemented in short time. > c) Peter Wemm checks in bike_sched > > The second seems much more logical, given our desire to become > performance competitive with Linux. However, sched_lock is not > currently FreeBSD's biggest bottleneck, and thus the first would be > acceptable. I would still be pleased at the possibility of sun4v > someday being checked into CVS. > I don't have objection. :-) > -Kip David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 09:23:43 2006 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1E2FC16A4ED; Mon, 10 Jul 2006 09:23:39 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <44B21C9A.3010800@freebsd.org> Date: Mon, 10 Jul 2006 17:23:38 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060519 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kmacy@fsmware.com References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , threads@freebsd.org, Robert Watson , Julian Elischer , freebsd-threads@freebsd.org Subject: Re: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:23:43 -0000 Kip Macy wrote: > > Apart from real time scheduling functionality I have yet to see any > real-world technical deficiencies with libthr. I have, however, seen > major stability issues with KSE. > > Network Appliance abandoned FreeBSD as a platform for running their > simulator due to frequent hangs caused by signals. More recently, on > sun4v, when single stepping csup (or any multi-threaded app for that > matter) the debuggee would often get the SIGTRAP and not GDB. When > re-starting mysqld for the second or third time the process would > become unkillable. These problems are not entirely surprising, KSE > makes signal handling *very* complicated. I am disappointed that > threads are currently unusable on sun4v with KSE. > > I would be delighted if sometime in the very near future, one of the > following happened: > 1. > a) Somebody steps up to work on KSE and fixes the signal issues that > have long plagued it. John Birrell or Paul Saab can make a T2000 > available to any motivated developer. > > 2. > a) David Xu fixes static linking with libthr I really want somebody who is familiar with weak symbol to help me, since both libthr and libc are using weak symbols (our ABI), according to what my fellows here said, weak symbols are picked up by linker randomly, so how to fix it? I had dicussed this issue with dan, but never got a satisfied answer. > b) David Xu exports support for real-time scheduling via libthr This can be implemented in short time. > c) Peter Wemm checks in bike_sched > > The second seems much more logical, given our desire to become > performance competitive with Linux. However, sched_lock is not > currently FreeBSD's biggest bottleneck, and thus the first would be > acceptable. I would still be pleased at the possibility of sun4v > someday being checked into CVS. > I don't have objection. :-) > -Kip David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 11:03:27 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org 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 A175516A51A for ; Mon, 10 Jul 2006 11:03:27 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B275B43D70 for ; Mon, 10 Jul 2006 11:03:22 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6AB3MC3055801 for ; Mon, 10 Jul 2006 11:03:22 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6AB3LcI055797 for freebsd-threads@freebsd.org; Mon, 10 Jul 2006 11:03:21 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jul 2006 11:03:21 GMT Message-Id: <200607101103.k6AB3LcI055797@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 11:03:27 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can s [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT s [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha s [2001/11/26] bin/32295 threads pthread dont dequeue signals s [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe s [2002/06/27] threads/39922threads [threads] [patch] Threaded applications e s [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z s [2003/03/10] threads/49087threads Signals lost in programs linked with libc 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/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/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag s [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/07/22] threads/83914threads [libc] popen() doesn't work in static thr s [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/20] threads/85160threads [libthr] [patch] libobjc + libpthread/lib p [2005/11/19] threads/89262threads [kernel] [patch] multi-threaded process h o [2005/12/12] threads/90278threads libthr, ULE and -current produces >100% W o [2006/01/03] kern/91266 threads [threads] Trying sleep, but thread marked s [2006/03/15] threads/94467threads send(), sendto() and sendmsg() are not co o [2006/06/01] threads/98256threads gnome-system-monitor core dumps from pthr 28 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f s [2001/09/09] threads/30464threads pthread mutex attributes -- pshared s [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from s [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/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [libc_r] [patch] libc_r close() will fail 11 problems total.