Date: Fri, 7 Jun 1996 22:07:40 -0600 From: Nate Williams <nate@sri.MT.net> To: Michael Hancock <michaelh@cet.co.jp> Cc: Nate Williams <nate@sri.MT.net>, 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: <199606080407.WAA02519@rocky.sri.MT.net> In-Reply-To: <Pine.SV4.3.93.960608112739.15024A-100000@parkplace.cet.co.jp> References: <199606080221.UAA02108@rocky.sri.MT.net> <Pine.SV4.3.93.960608112739.15024A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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? 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. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080407.WAA02519>