I don't understand what this whole RCU business achieves. It's trivially completely wrong: the RCU pointer is stuffed into a larger structure that might be deleted anyways, nothing's actually protected. And it seems that you fitted all the metrics into one value that is small enough to be atomic anyways, so is RCU needed at all?

This is lacking the bigger picture. We can't just break the proof format with every version. What's the format of a proof you are moving toward?

In D9760#222098, @josephroyking wrote:

If this solves the fbt issues, it's a step in the right direction.

Looking at react-intl, it seems to me like it is a significant step backward.

A couple of questions, but this looks much better now.

The description fo this patch makes no sense. We aren't using the scheduler to read delegations. I do not know why this lock is needed. It seems to me that creating the avalanche state once the delegation has been verified should be enough.

I think that should be merged in D9742 . it doesn't make much sense to separate the code and the tests.

Rebase on D9751 to remove circular dependency

Reoder fields a bit, based on D9750

Get back to unordered_set XD

Fix mismatch between unordered and ordered sets.

Why does the peer manager depends on et processing?

The general approach seems to make sense, but holly hell, the code is a total mess. You need to think about what these different function do, or should do, and ventilate accordingly, instead of just patching things in random places.

It looks like to me this got a bit out of control. In D9637, you split FormatSubVersion in two, and in this, you do it again. At this rate, 8 more patches and we get 1024 variation of that function.

You have a fundamental problem here. You can register a node for 2 proofs and 2 keys. In addition, the key seems duplicated between the PeerManager and the node state. Is it used at all in the peer manager? If not, then get rid of it. In any case, you need to resolve this duplication problem.

uint8 is just 256 values, this would make it impossible to CPU mine on testnet or whatnot.

No, this is not thread safe.

Back on your queue, this seems to be breaking tests.

This whole approach do not seem very sensible to me.

Because the pointer is set and never mutated, you actually don't need the mutex to access the pointed data - which are immutable. The scope of these lock is too large. buildRemoteSighash for instance, shouldn't need the lock.

Why?

This honestly seems like a step backward. The thing throws JSONRPC errors, so that most certainly belong in the RPC stack.

Abandoning in favor of D9634

rebase

Rebase on top of D9629