Updater thread may screw up any active workers threads that are scanning plot files at the same time

[quetzalcoatl]

I've found yet another bug in Blago, inherited from andzno1's dual-mining mod..

When you mine BURST which has "POC2StartBlock"=502000, and also other coins with different POC2StartBlock (i.e. 0 as in all other coins), then depending on pure luck, the round-updater which fetches blockheight/rounddata from the pool, may screw up the workers that scan plot files and calculate deadlines at that moment.

That's because every coin has its own 'updater' that pools a different server, and every coin has its own POC2StartBlock setting, but there is only one global flag that is used to control whever current mining uses POC1 or POC2 algorithm. This means, that with bad timings, mining threads may start working on a BURST with high block height and "POC2StartBlock"=502000 and POC2 mode enabled, and in the meantime an updater thread of another coin may switch the mode to POC1.

blagominer.h

// PoC2
extern bool POC2;                               // true if PoC2 is activated

worker.cpp

        //PoC2 cache size added (shuffling needs more cache)

        if (p2 != POC2) {
            if ((stagger == nonces) && (cache_size2 < stagger)) cache_size_local = cache_size2;  // optimized plot
            else cache_size_local = stagger; // regular plot
        }

and the oscar goes to pollLocal from network.cpp

    //POC2 determination
    if (getHeight(coinInfo) >= coinInfo->mining->POC2StartBlock) {
        POC2 = true;
    }

This is a bug, but a strange one. It should not have any effect for any valid configuration. BURST is already in POC2 phase, and all other coins are in POC2 right from block 0, so updater threads working in parallel with miners may only set the POC2 flag to true. There's no normal setup where POC2 flag would be turned back to false.

However, it still needs to be fixed, and while at it, it would be good to inspect/refactor the code and see if there are any other similar surprises left there.

[quetzalcoatl]

Probably solved in v2.300003.0

[quetzalcoatl]

Actually, solved in v2.300003.1 (72c320fe37c4fc9e1fc89044586fffd84d3a8517)