1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1QgTgi-0007jo-Kj
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 03:31:08 +0000
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;
Received: from mail-pv0-f175.google.com ([74.125.83.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QgTgh-0001cf-Ql
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Jul 2011 03:31:08 +0000
Received: by mail-pv0-f175.google.com with SMTP id 24so4455610pvf.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Jul 2011 20:31:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.43.10 with SMTP id q10mr2392663wfq.239.1310441467427; Mon,
11 Jul 2011 20:31:07 -0700 (PDT)
Received: by 10.143.58.19 with HTTP; Mon, 11 Jul 2011 20:31:07 -0700 (PDT)
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
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QgTgh-0001cf-Ql
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2011 03:31:08 -0000
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
|
