Date: Sun, 9 Jun 1996 00:23:01 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Nate Williams <nate@sri.MT.net> Cc: Terry Lambert <terry@lambert.org>, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: The -stable problem: my view Message-ID: <Pine.SV4.3.93.960609000342.18536A-100000@parkplace.cet.co.jp> In-Reply-To: <199606080407.WAA02519@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Jun 1996, Nate Williams wrote: > > > > Terry proposes a set of tools to help enforce the policy of always having > > ^^^^^^ > > > > I said help not guarantee. The tools would help resolve reads while > > commits are being done. Multiple reader/single writer locks are a cheap > > effective way to do this. > > They wouldn't enforce or even help the policy. Multiple reader/single > writer locks don't solve any significant problem we've faced. Why do > something that limits the ability of developers to commit changes when > the problem the fix happens .001% of the time? So what's the commit protocol now, e-mail? This sounds more limiting on a developer's schedule no matter how many committers there are. I assume there are more than two and they would probably rather focus on writing code than coordinating commits manually. > It's like making a loop that gets called once at initialization time 50% > faster while you leave the sorting algorithm which takes up 95% of CPU > time alone. It's doesn't buy you anything but a warm fuzzy feeling. I'm not convinced this analogy holds. With all the problems I saw over the last 2 weeks it sure seemed like more than a slip of commit discipline. -mike hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960609000342.18536A-100000>