- User Since
- May 14 2017, 13:52 (220 w, 2 d)
Mon, Aug 2
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?
Thu, Jul 29
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?
Tue, Jul 27
Thu, Jul 22
Wed, Jul 21
Tue, Jul 20
Mon, Jul 19
Looking at react-intl, it seems to me like it is a significant step backward.
Sat, Jul 17
A couple of questions, but this looks much better now.
Mon, Jul 12
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.
Sun, Jul 11
Sat, Jul 10
I think that should be merged in D9742 . it doesn't make much sense to separate the code and the tests.
Fri, Jul 9
Thu, Jul 8
Rebase on D9751 to remove circular dependency
Reoder fields a bit, based on D9750
Get back to unordered_set XD
Wed, Jul 7
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.
Jun 28 2021
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.
Jun 24 2021
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.
Jun 23 2021
Jun 20 2021
Jun 18 2021
Jun 17 2021
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.
Jun 15 2021
Jun 14 2021
Jun 10 2021
Jun 8 2021
Jun 7 2021
Jun 6 2021
This honestly seems like a step backward. The thing throws JSONRPC errors, so that most certainly belong in the RPC stack.
Jun 4 2021
Abandoning in favor of D9634