From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:03:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12DFE16A42F for ; Thu, 21 Jul 2005 14:03:00 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from oneyou.mcmli.com (oneyou.mcmli.com [216.194.67.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3C043D60 for ; Thu, 21 Jul 2005 14:02:49 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (pcp01267574pcs.danbry01.ct.comcast.net [68.63.157.203]) by oneyou.mcmli.com (Postfix) with ESMTP id A516D5B86 for ; Thu, 21 Jul 2005 10:02:48 -0400 (EDT) Received: from XPMM (unknown [63.119.50.193]) by sentry.24cl.com (Postfix) with ESMTP id 2A86E5101 for ; Thu, 21 Jul 2005 10:02:48 -0400 (EDT) Message-ID: <200507211002580001.03E5249D@sentry.24cl.com> In-Reply-To: <20050721135839.K97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> X-Mailer: Courier 3.50.00.00.1081 (http://www.rosecitysoftware.com) (P) Date: Thu, 21 Jul 2005 10:02:58 -0400 From: "MikeM" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:03:00 -0000 On 7/21/2005 at 2:29 PM Robert Watson wrote: |Some of us have actually spent quite a bit of time looking at the defect |sets reported for 5.x. Depending on the release they fall into a number |of categories, but here are the major ones I've identified: | [snip] |- Network stack stability under high load, especially on SMP. Many of | these bugs had to do with exercising timing and race conditions | "precisely right", and involved workloads not in the standard set of | testing performed. In many cases, those workloads have now been added | to the regression test suite. For example, there were a number of race | conditions relating to the closing of sockets and network stack teardown | in the protocols. These tended to turn up on systems running tens of | thousands of rapidly opening and closing TCP connections on SMP | hardware. Reproducing those conditions is difficult, and not something | most FreeBSD developers have the resources to do, so have to wait for | bug reports from people who do have those resources. | [snip] ============= Thank you for the clear answer. For the record, I am very pleased with the overall quality of FreeBSD, my comments were only meant in the sense of "everything has room for improvement", even something as excellent as FreeBSD. I snipped out one section of your reply because it illustrates a main point of my message. While it is good to have the testing in place to catch race conditions, has anyone done a post mortem to determine why and/or how the race conditions got into the code in the first place? *Someone* coded that race condition. Was it that two developers were using the same data structure without one knowing about the other? If so, then there's a problem that needs to be fixed. Chances are, though, that wasn't the problem. Only the developers would be able to look at the development process and determine why the process allowed a race condition to occur in the code. But if they took the time to do this, then the knowledge gained would be useful across a wide swath of FreeBSD development. Thank you for your offer of allowing me to contribute to the FreeBSD project, however I have professional obligations that prevent me from making the necessary commitment to the project. For the most part I just lurk here, popping my head up on occasion. In doing so, it is not my intent to to snipe at anyone or carp at anything. As such, I'll let this sub-thread die out at this point....