The threads of a windows Qt client look rather constant. procexp.exe lists 16 (14 if on Tor), always same "start addresse" and activity level.
Perhaps it's 1 less when stopped syncing.
If not.. hasn't this problem gotten worse (not so good idea to use newest possible boost version that doesn't cause compile error)?
Perhaps it's 1 less when stopped syncing.
If not.. hasn't this problem gotten worse (not so good idea to use newest possible boost version that doesn't cause compile error)?
I think that the QT problem is some race condition that causes some kind of deadlock
Good call, could it by any chance be this one...
https://github.com/alexwaters/Bitcoin-Testing/blob/master/src/net.cpp#L461
https://github.com/chronokings/huntercoin/blob/master/src/net.cpp#L462
I've not checked it, but yes, I strongly assume that there are quite some deadlocks and race conditions in the old code. If you find any, feel free to submit a pull request.
Regarding the upcoming client: Anyone can see the code and test it, https://github.com/domob1812/huntercore. It is able to sync the full chain already (but go ahead and try it if you want!). There are two main things missing before you can use it for playing: First, the tx fee policy is not yet updated to the custom name_update fees; that means that your transactions will likely get stuck and not mined. Second, while the general blockchain logic does support game transactions (as it needs those to verify the chain), the wallet won't yet see them. Both should be relatively straight-forward to implement, it just depends on how much time I can spend on it (as this is my free time and I've just gone through a move and a new job).
