Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.175 as permitted sender)
	client-ip=74.125.83.175; envelope-from=gavinandresen@gmail.com;
	helo=mail-pv0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
References: <97305540.4426247.1310337435268.JavaMail.fmail@mwmweb052>
	<CANEZrP1gEx0_A+BQfJLQ1jppc=-qS1DwruR_wXsP-ctqZGGnjA@mail.gmail.com>
Date: Tue, 12 Jul 2011 13:31:07 +1000
Message-ID: <CABsx9T0vLghciEbx8jCEGzLGLC5LJuzRXkMGEVf9hqfESWwjVg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
Precedence: list

It is SO tempting to start over from scratch, isn't it?

We'll just tell everybody to stop using bitcoin so much for six months
or so while we implement a much better client.  It will be exactly
like the bitcoin we have now, except with a much nicer internal
architecture and much cleaner code-base, and we're pretty sure we can
get it done in six months if everything goes exactly as planned.

I think incremental improvement of the "devil we know" is the right
thing to do right now, although I'm going to spend more time thinking
about how to make sure different bitcoin implementations work well
together (I've started working on network-protocol-level testing).

Regarding Michael's specific suggestions:  the
lots-of-threads-and-mutexes architecture of the client bothers me
because it is too easy to change code and create a deadlock that is
very hard to debug and fix. Switching to asynchronous IO might be the
right thing to do.  Then again, it might be easier to modify the
CRITICAL_SECTION code to detect and report deadlocks (anybody have
experience doing that?).

-- 
--
Gavin Andresen