suggestion to clean on miner exit

[adevelopcr]

I saw the pull request here :
#1885

And saw that you was using shutdown in executor from another thread .
Instead : you had to make an event which you push from shutdown and the event will be handled in ex_main where the exit process will be done then the ex_main will return and at this moment you are waiting for its return from shutdown function

Also the method you use to wait for the mining threads to finish is very bad
You should store the id of every thread you want to wait for and use OpenThread/WaitForSingleObject even if the thread exited before you will know and return immediately without waiting

I saw also that you are checking for bQuit in multiwork main in one point which is reached every minute nearly or more . Instead, you had to check for it also in the inside while loop which is repeated every time in less than second and you can also make bSuspend to be able to pause and resume the threads and make both bQuit and bSuspend as pointers bool * in iBackend struct then they will be shared across iBackend and minethd

You can also implement your class thread as I've done and it is the same with std::thread except it has join/timed join and it uses WaitForSingleObject which is more flexible than waiting with a bool variable

You also forgot to close all the pools and delete the telemetry
You need to delete the mutexes you allocated and the arrays you allocated

I know most of these cleaning operations aren't necessary if the miner process is being terminated but I use it to be able to shutdown the executor then restarting with the config file or parameters changed

I for now miss the cleaning up for gpu mining threads as I have no experience with OpenCl or Cuda
I hope you will commit them soon

[adevelopcr]

@psychocrypt

[psychocrypt]

The feature should clean up the gpu stuff as clean as possible. The cpu side is not as important but many gpu driver are so instable that they can not handle a force close very well. Also in the event of an gpu crash it is not possible to join a gpu thread because this will result in a freez. The current PR is still work in progress.

[adevelopcr]

But if there is a gpu crash or even cpu (not c++ exception) the whole program will be terminated gracefully by windows so no meaning of waiting for them as no miner is running

SEH exceptions may save the miner from being terminated but it's very better to exit and debug than continuing after such crash except few situations where you are sure that everything is fine

[psychocrypt]

Maybe it is the case in windows for AMD GPUs in other OS this is not the case. Also this behavior can not be guaranteed.

[cppdev-123]

@psychocrypt if the gpu thread crash will this terminate the program with its all cpu and gpu threads or the only gpu thread will be killed and the other will continue to function ?

If the remaining threads will continue to work then I can use a timestamp for each thread which every thread will update it repeatedly

And when joining the threads the used function will check for timestamps and compare them with current time and only active threads will be joined

[adevelopcr]

@psychocrypt
Can you clear up this ?

[Spudz76]

If the GPU thread crashed, the PCI bus could be hung, and the GPU is definitely not in any known state and probably won't warm-reset properly. So then nobody knows what other threads might be able to do, which ones hang forever and which ones can continue. It's a dice-roll every time. By definition this calls for a reboot, not a thread massage.

Usually thread crashes are from hardware problems (bad psu, bad heat removal, bad risers, bad connectors...) so trying to continue at any cost would actually just melt/destroy hardware. Better to have a daily crash until moron operator investigates their hardware?

I still agree with all the user-pausing features, focus on that more than auto thread recovery (which won't work like you expect).