Topic: [ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain - page 112. (Read 879724 times)

thanks merged it.

Ok, instant pull request 
https://github.com/chronokings/huntercoin/pull/99

 db-4.8.30 - this is what i use when compile on windows with easywinbuilder - afaik

if you use 4.7.25 then it won't be backward compatible ..

https://forum.namecoin.info/viewtopic.php?p=6599&sid=97133373c5280a5a9a20286e79310462#p6599

I changed the code a bit and  start synchronization with zero, I hope synchronization will not stop more.
By the way what BDB version do you use by default on Windows? I tried db-4.7.25.NC but Huntercoin-Qt could not open the database...

Yes, such a caching as you describe is possible.  However, I don't think that's the point of the core daemon.  Instead, such caches (backbuffer, as you call it) can be added by an additional layer in case that's necessary for performance.  I think that the daemon should just handle blocks and transactions and all that robustly, and allow clients to query that data in as simple a way as possible.

That said, of course it should not cause deadlocks.  I've found and fixed some, which were due to inconsistent order of locking when multiple locks were required for some action.  (The ones I've found between cs_main and the wallet lock, mostly.)  Probably the same thing happens with cs_mapTransactions and cs_main.  If I find time, I'll take a look.

Not locking at all seems not like a good idea.  Even though, as you observe, it will "mostly" work if I'm just reading data, one could indeed get into a bad situation while accessing memory that is just being changed (e. g., internally by the stl::map or something).  In the worst case, this could crash the daemon (something like this happened with libcoin due to exactly this reason).  We should not open that can of worms just for perceived "performance optimisation".  If the locking is a performance issue for your calls, you should wrap your own cache around them.  (Or, if it is a common problem for various clients, we could develop a "standard layer" like NMControl for Namecoin - but it should not be part of the core daemon.)

I just know that looping requests to name_pending cause some locks, so that's the only thing i can say (call to name_pending RPC procedure), i don't have control over the overall huntercoin process and can't debug it
if you try to put a name_pending into a loop every 5 seconds you should notice the problem, maybe you have more chance to debug into the deadlocked code

anyway talking about name_pending and other parts of code that uses many locks, wouldn't be possible to use some backbuffer and flip them when needed? this is what i do in my behaviours when parsing game status and i need to do some time consuming things on that data:

e.g. in your case, when you process a new block and generate a new game_state, you lock everything, preventing all "readonly commands" to be processed, while you could process the new game_status into a back buffer, then once it has been processed, you then apply a lock and swap the new game_state with the old. this isn't the right example, i suppose game_state isn't processed this way, but wanted just to point out the generic problem.

Maybe looking at the code of name_pending would more useful:
i see that you apply this lock:

CRITICAL_BLOCK (cs_mapTransactions)
CRITICAL_BLOCK (cs_main)

and i see that those locks are applied in many transactions, why?
I mean, name_pending just read data, and i think isn't important if data is really updated with ms precision, because being all multithreaded, once it's returned value is used, it could have already been changed, so the lock is only useful to prevent memory faults when reading a memory while it is written, but... why don't just use back buffer here, where the writing processes write on a back buffer then use locks just to swap new data with old one? this would improve drastically the performance of the daemon, reducing a lot deadlocks problems.
I don't know QT and i don't know how it handle multithread arrays, but maybe there is even a way to read from a multithread safe array without even worrying about locks, that are handled internally and are applied only to write (but this is just a guess)

not sure if i explained well what i mean

just leaving it running.
just running the daemon and not issuing any commands.

Yes, there are probably some deadlocks in the code.  If you spot a particular one, please open an issue on Github.  Should be relatively easy to check for correct locking in a particular case (when I know where to look at).

@FSB

are you issuing any commands like name_pending?
or just leaving it running?

my client shouldn't have nothing to do with the problem, i'm running it without problem since months (using it actually to play not just to leave it open)
however i noticed some problem when calling name_pending command often, sometimes calling it stuck the daemon, i think this has something to do with some deadlock in huntercoind code or something like that, that should be checked extensively (the code contains too much locks around)
(My client doesn't use name_pending automatically, so couldn't trigger this problem neither)

are you using mm client or just running the daemon and not issuing any commands?

what about debug.log?

Not really
I still have this problem: http://forum.huntercoin.org/index.php/topic,163.0.html
For example, currently sync stopped at "blocks" : 574139

I want to find someone who also has the problem that is easier to understand why it occurs.
On Linux, the client seems to work fine...

i leave running 247 on linux (ubuntu) - never lost sync once..

on windows I leave running for a couple of days at a time and no issues... although i do remember in the past having to restart the daemon on windows once or twice (using mm client, but unrelated to that afaik). edit: I think this issue was something to do with name_list bug.. i believe this is fixed now

How many people have this problem:
??
And on what operating system?(Only Windows or Linux + Windows?)

You're welcome 

Aaaand we have a winner!!  

Many thanks fsb4000 - up & running again. It would be great if the devs here would provide links to pre-compiled Linux binaries also, saving all these compilation problems every time a new version is released.

Peace 

Yes. I have.
(Don't forget to create huntercoin.conf with rpcuser, rpcpassword, rpcallowip=127.0.0.1 and maybe other parameters)
Huntercoind(64 bits): https://yadi.sk/d/vlfTJasYegew6

Hi fsb4000,

Do you also have a compiled & working huntercoin daemon? I don't run the full QT version on my rigs & it's the daemon that is refusing to run, even though it compiles without any errors. I'd really appreciate it if you could do this so I can try it 

Peace 

Hi!
I compiled linux binary(64 bit)(huntercoin-qt): https://yadi.sk/d/RkGoHONvegUwC

Mandatory Update - HardFork Huntercoin v1.2 - Improve PvP & Bot Reduction

Increase General Cost from 10 HUC -> 200 HUC
Increase Carrying Capacity to 2000 HUC
Reduce Heart Spawn to 1/500 Blocks
Reduce Destruct Radius of Generals to 1 Square Radius (same as hunters)
Remove Hearts at Disaster
Reintroduce Spawn Death after 30 Blocks - But, if you die this way, the coins are returned to you in full.
Rename "lost coins" (originally for coins lost when the crown is not being held) to "gamefund" - this can be seen in game_getstate
Add coins on Generals (including cost) who die whilst Poisoned (from Disaster) to "gamefund" instead of dropping on the floor. These coins will be used in a future update - Add to the Crown and into NPCs or by other methods.

Must update before block 590k < 2 weeks  -- (240k on testnet).

Windows Binaries
https://mega.co.nz/#!gF8hVQIB!IklEUCt0RQpu7RHSl4A0I3VYIXDSkDVhRqBIOA7Jr4w
Source
https://github.com/chronokings/huntercoin