CriticalSection has been fixed! Thanks

Thank you for the great analysis. (

This time, IPV6 is enabled as standard, and the placement of CriticalSection is changed.

Next time, we will implement RPC thread pool and verify with testnet.

In order to prevent deadlocks, we would like to put a mechanism like the message queue implemented in Windows.

The RPCs that need to proceed after processing has been processed reliably are like SendMessage, and if there are no problems asynchronously by accumulating in the queue with RPCs are processed efficiently with a mechanism like PostMessage.

Also, if we consider only the PostMessage part instead of thinking about the scope of CriticalSection, it can prevent deadlock even if it is complicated.

We will fix CriticalSections that classified according to the RPC processing issued by the mining pool

We will fix CriticalSections that classified according to the RPC processing issued by the mining pool.
※ Ultimately, CriticalSection is expected to be narrowed down to one.

As for this processing part, FIXME was attached, and it was operating abnormally with PoMP of NOMP.

This time, YiiMP PoW had a problem, so I decided to go back to the original CriticalSection and see what it was.
However, if it is this, it will not work with NOMP.
Therefore, it will be divided by the macro of the compiler.

As an improvement method,
I think that this RPC itself will be like this as Windows PostMessage, so that it will be issued one by one after being accumulated.
※ The current situation is similar to SendMessage that some of them do not work.

In addition, if this improvement is implemented, all RPCs will be affected, so I think that it will be released after testing with testnet.


本日は、 ドライブの故障を予測するとされているS.M.A.R.T.の怖さを改めてまとめます。