mirror of https://github.com/ethereum/go-ethereum
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tag:
Branch:
Tree:
68ac4eb796
ChrisChinchilla-patch-1
ChrisChinchilla-patch-3
appveyorfix
buildbot-testing
ci-i386-disable-cache
docs/fix-pkg-url
documentNavScroll
gh-pages
kaustinen-with-shapella
manual-local-cache
master
msgrater
pa
poc8
release-1.14.9
release/0.9.36
release/1.0.0
release/1.0.1
release/1.1.0
release/1.10
release/1.11
release/1.12
release/1.13
release/1.14
release/1.2.1
release/1.3.0
release/1.3.2
release/1.3.3
release/1.3.4
release/1.3.5
release/1.3.6
release/1.4
release/1.5
release/1.6
release/1.7
release/1.8
release/1.9
revert-25955-goja1
revert-26265-console/eth_call
revert-26290-generic-prque-extended
revert-30495-sim-backend-rollback-tip
s1na-patch-1
s1na-patch-2
test_travis
unbork-master
website
website-fix-list-margin
website-matomo
0.2.2
0.3.0
0.3.1
0.5.13
0.5.14
0.5.15
0.5.16
0.5.17
0.5.18
0.5.19
0.9.16
0.9.23
1.2.1
2
PoC6
buildbot-testing-tag-3
poc1
poc5-rc1
poc5-rc10
poc5-rc11
poc5-rc12
poc5-rc2
poc5-rc3
poc5-rc4
poc5-rc6
poc5-rc7
poc5-rc8
poc5-rc9
v0.4.1
v0.4.2
v0.4.3
v0.6.0
v0.6.3
v0.6.4
v0.6.5
v0.6.5-1
v0.6.5-2
v0.6.6
v0.6.7
v0.6.8
v0.7.10
v0.7.10-broken
v0.7.11
v0.8.4
v0.8.4-1
v0.8.5
v0.8.5-2
v0.9.17
v0.9.18
v0.9.20
v0.9.21
v0.9.21.1
v0.9.22
v0.9.23
v0.9.24
v0.9.25
v0.9.26
v0.9.28
v0.9.30
v0.9.32
v0.9.34
v0.9.34-1
v0.9.36
v0.9.38
v0.9.39
v1.0.0
v1.0.1
v1.0.1.1
v1.0.1.2
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.1.0
v1.1.1
v1.1.2
v1.1.3
v1.10.0
v1.10.1
v1.10.10
v1.10.11
v1.10.12
v1.10.13
v1.10.14
v1.10.15
v1.10.16
v1.10.17
v1.10.18
v1.10.19
v1.10.2
v1.10.20
v1.10.21
v1.10.22
v1.10.23
v1.10.24
v1.10.25
v1.10.26
v1.10.3
v1.10.4
v1.10.5
v1.10.6
v1.10.7
v1.10.8
v1.10.9
v1.11.0
v1.11.1
v1.11.2
v1.11.3
v1.11.4
v1.11.5
v1.11.6
v1.12.0
v1.12.1
v1.12.2
v1.13.0
v1.13.1
v1.13.10
v1.13.11
v1.13.12
v1.13.13
v1.13.14
v1.13.15
v1.13.2
v1.13.3
v1.13.4
v1.13.5
v1.13.6
v1.13.7
v1.13.8
v1.13.9
v1.14.0
v1.14.10
v1.14.11
v1.14.2
v1.14.3
v1.14.4
v1.14.5
v1.14.6
v1.14.7
v1.14.8
v1.14.9
v1.2.2
v1.2.3
v1.3.1
v1.3.2
v1.3.3
v1.3.4
v1.3.5
v1.3.6
v1.4.0
v1.4.1
v1.4.10
v1.4.11
v1.4.12
v1.4.13
v1.4.14
v1.4.15
v1.4.16
v1.4.17
v1.4.18
v1.4.19
v1.4.2
v1.4.3
v1.4.4
v1.4.5
v1.4.6
v1.4.7
v1.4.8
v1.4.9
v1.5.0
v1.5.1
v1.5.2
v1.5.3
v1.5.4
v1.5.5
v1.5.6
v1.5.7
v1.5.8
v1.5.9
v1.6.0
v1.6.1
v1.6.2
v1.6.3
v1.6.4
v1.6.5
v1.6.6
v1.6.7
v1.7.0
v1.7.1
v1.7.2
v1.7.3
v1.8.0
v1.8.1
v1.8.10
v1.8.11
v1.8.12
v1.8.13
v1.8.14
v1.8.15
v1.8.16
v1.8.17
v1.8.18
v1.8.19
v1.8.2
v1.8.20
v1.8.21
v1.8.22
v1.8.23
v1.8.24
v1.8.25
v1.8.26
v1.8.27
v1.8.3
v1.8.4
v1.8.5
v1.8.6
v1.8.7
v1.8.8
v1.8.9
v1.9.0
v1.9.1
v1.9.10
v1.9.11
v1.9.12
v1.9.13
v1.9.14
v1.9.15
v1.9.16
v1.9.17
v1.9.18
v1.9.19
v1.9.2
v1.9.20
v1.9.21
v1.9.22
v1.9.23
v1.9.24
v1.9.25
v1.9.3
v1.9.4
v1.9.5
v1.9.6
v1.9.7
v1.9.8
v1.9.9
${ noResults }
Felföldi Zsolt
4eb9296910
This PR adds an extra guarantee to NodeStateMachine: it ensures that all immediate effects of a certain change are processed before any subsequent effects of any of the immediate effects on the same node. In the original version, if a cascaded change caused a subscription callback to be called multiple times for the same node then these calls might have happened in a wrong chronological order. For example: - a subscription to flag0 changes flag1 and flag2 - a subscription to flag1 changes flag3 - a subscription to flag1, flag2 and flag3 was called in the following order: [flag1] -> [flag1, flag3] [] -> [flag1] [flag1, flag3] -> [flag1, flag2, flag3] This happened because the tree of changes was traversed in a "depth-first order". Now it is traversed in a "breadth-first order"; each node has a FIFO queue for pending callbacks and each triggered subscription callback is added to the end of the list. The already existing guarantees are retained; no SetState or SetField returns until the callback queue of the node is empty again. Just like before, it is the responsibility of the state machine design to ensure that infinite state loops are not possible. Multiple changes affecting the same node can still happen simultaneously; in this case the changes can be interleaved in the FIFO of the node but the correct order is still guaranteed. A new unit test is also added to verify callback order in the above scenario. |
4 years ago | |
---|---|---|
.. | ||
nodestate.go | p2p/nodestate: ensure correct callback order (#21436) | 4 years ago |
nodestate_test.go | p2p/nodestate: ensure correct callback order (#21436) | 4 years ago |