Date: Sat, 31 Mar 2012 14:28:28 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael =?iso-8859-1?Q?Gr=F8nager?= <gronager@mac.com>
Message-ID: <20120331122827.GA15726@vps7135.xlshosting.net>
References: <201203310003.18599.luke@dashjr.org>
	<20120331105401.GA14117@vps7135.xlshosting.net>
	<FF86C935-B407-4983-BCB2-61A79DAF8DB8@mac.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <FF86C935-B407-4983-BCB2-61A79DAF8DB8@mac.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.7 merge recommendations/status
Precedence: list

On Sat, Mar 31, 2012 at 01:16:56PM +0200, Michael Gr=F8nager wrote:
> If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/li=
bcoin) and then you could build bitcoind bitcoin-qt on libcoin.
>=20
> libcoin solved most of the problems you list below. And if you worry ab=
out the copyright/license I am also willing to change that to make it fit=
.

Thanks for that - without a license change it would not be possible to me=
rge anything.

> libcoin have no global thread mutexes and and there is no blocking of t=
he main thread due to rpc methods (except for a sendto), further, e.g. a =
reorganize only locks the main thread for a split second while the final =
commit is done.=20

Yes, I like its design and refactorings a lot, but at the same time it's =
very large change to accept at once. In particular, I'm not entirely conv=
inced yet about its thread-safety. For example, acceptblock is a public m=
ethod, but it seems (i may be missing something) to grab no lock at all u=
ntil setBestBlock or reorganize is called. Is it impossible to call accep=
tBlock twice simultaneously? One may start with a bestblockindex value th=
at gets modified a split second later by a simultaneous call. It may be t=
he case that there are indeed no possibilities for this to happen because=
 of things I'm missing, but although I'm a big fan of well-encapsulated l=
ocks and the use of reader-writer locks, it's hard to verify whether you =
use them enough. My suggestion would be: make each publicly accessible me=
thod of BlockChain grab either a reader lock (if it's a const function) o=
r an upgradable lock, and take a writer lock in each method that actually=
 performs changes.

> The libcoin rpc supports keep_alive and pipelining, runs in its own thr=
ead (but can also run in the same thread as the node) and uses async oper=
ation. Ipv6 is easy to implement in libcoin as the CAddress/Endpoint clas=
s is implemented as a subclass of boost::endpoint, only thing holding bac=
k is deciding on an ipv6 format on IRC, and, I then I would really like t=
o reverse the order of the last 12 bytes in the address db (they are oppo=
site to boost).

Not sure what you mean: the serialized combination of the 32-bit IPv4 add=
ress and 12 bytes padding in CAddress are exactly a bsd socket library in=
6_addr in network byte order. In 0.6.0, CAddress derives from CNetAddr, w=
hich encapsulates these 16 bytes.

--=20
Pieter