enable_device should not modify mining_threads because this is unsafe after initialization. it is also not necessary in most cases where it is currently used, except in initialization
refactored some of the new restart_mining_threads code and incorporated above change for better stability
properly handle disabled devices in restart_mining_threads when opt_removedisabled is set
total_devices was set incorrectly if the disabled devices were not at the end of devices, so total_devices is now always the number of detected devices, since that is what is in the devices variable
This mode/setting is unusable left-over from SHA-256 cgminer. It does not work with Scrypt or other algorithms that are used in sgminer. Removed in single commit so it can be used as reference, if benchmark mode is added in the future.
Fixed an issue where the GPUs would be initialized on first pool alive,
but the mining threads would end up being initialized on another pool
because it was selected right away.
Updated Algorithm switcher to change on pool rather than on algorithm.
This way if, for example, 2 pools use the same algorithm but different
GPU settings, the settings will be applied when changing pool.
Additionally:
* Included a "common" algorithm type in API pool/profile listing. For
example using "marucoin-mod" will return "X13", "darkcoin-mod" will
return "X11", scrypt + nfactor != 10 will return "NScrypt", etc...
* Added "kernel" config option to be backwards compatible with other
miners' configs.
* Added a few algorithm aliases: x11mod -> darkcoin-mod, x13mod ->
marucoin-mod...
* New config keyword: "includes", which holds an array of include files.
This is to counter the JSON limitation not allowing multiple values with
the same name, thus preventing inclusion of multiple files.
Sometimes the json parser, will read/apply nfactor before algorithm is set. When that is the case, set_algorithm() will reset nfactor to 10 preventing nscrypt from loading properly. Corrected the function to use previously set nfactor or default to 10.
Moved the GPU initialization block to happen when a pool is actually switched to. Sometimes the first pool alive isn't the first pool switched to. This would result in unnecessary kernel loading if the first pool detected alive isn't used right away.
