Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-12 🗒️ Summary of this message: Bitcoin's ...
📅 Original date posted:2011-07-12
🗒️ Summary of this message: Bitcoin's client needs a much better internal architecture and cleaner code-base, but incremental improvement of the current system is the right thing to do.
📝 Original message: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
🗒️ Summary of this message: Bitcoin's client needs a much better internal architecture and cleaner code-base, but incremental improvement of the current system is the right thing to do.
📝 Original message: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