Date: Thu, 21 Jul 2005 10:02:58 -0400 From: "MikeM" <the.lists@mgm51.com> To: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507211002580001.03E5249D>