From: Pieter Wuille <pieter.wuille@gmail•com>
To: "Michael Grønager" <gronager@mac•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] 0.7 merge recommendations/status
Date: Sat, 31 Mar 2012 14:28:28 +0200 [thread overview]
Message-ID: <20120331122827.GA15726@vps7135.xlshosting.net> (raw)
In-Reply-To: <FF86C935-B407-4983-BCB2-61A79DAF8DB8@mac.com>
On Sat, Mar 31, 2012 at 01:16:56PM +0200, Michael Grønager wrote:
> If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin) and then you could build bitcoind bitcoin-qt on libcoin.
>
> libcoin solved most of the problems you list below. And if you worry about 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 merge anything.
> libcoin have no global thread mutexes and and there is no blocking of the 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.
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 convinced yet about its thread-safety. For example, acceptblock is a public method, but it seems (i may be missing something) to grab no lock at all until setBestBlock or reorganize is called. Is it impossible to call acceptBlock twice simultaneously? One may start with a bestblockindex value that gets modified a split second later by a simultaneous call. It may be the 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 locks 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 method of BlockChain grab either a reader lock (if it's a const function) or 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 thread (but can also run in the same thread as the node) and uses async operation. Ipv6 is easy to implement in libcoin as the CAddress/Endpoint class is implemented as a subclass of boost::endpoint, only thing holding back is deciding on an ipv6 format on IRC, and, I then I would really like to reverse the order of the last 12 bytes in the address db (they are opposite to boost).
Not sure what you mean: the serialized combination of the 32-bit IPv4 address and 12 bytes padding in CAddress are exactly a bsd socket library in6_addr in network byte order. In 0.6.0, CAddress derives from CNetAddr, which encapsulates these 16 bytes.
--
Pieter
prev parent reply other threads:[~2012-03-31 12:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-31 4:03 Luke-Jr
2012-03-31 7:56 ` Wladimir
2012-03-31 10:54 ` Pieter Wuille
2012-03-31 11:08 ` Pieter Wuille
2012-03-31 11:16 ` Michael Grønager
2012-03-31 12:28 ` Pieter Wuille [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120331122827.GA15726@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@mac$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox