- 06 6月, 2016 5 次提交
-
-
由 Péter Szilágyi 提交于
(cherry picked from commit 4496a44f)
-
由 Péter Szilágyi 提交于
(cherry picked from commit 4f1d92b3)
-
由 Péter Szilágyi 提交于
(cherry picked from commit 8906b2fe)
-
由 Péter Szilágyi 提交于
(cherry picked from commit e86619e7)
-
由 Péter Szilágyi 提交于
(cherry picked from commit b40dc8a1)
-
- 12 5月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 16 4月, 2016 1 次提交
-
-
由 Felix Lange 提交于
Context keys must have a unique type in order to prevent any unintented clashes. The code used int(1) as key. Fix it by implementing the pattern recommended by package context.
-
- 15 4月, 2016 2 次提交
-
-
由 Felix Lange 提交于
-
由 Felix Lange 提交于
-
- 02 4月, 2016 1 次提交
-
-
由 Bas van Kervel 提交于
-
- 16 3月, 2016 2 次提交
-
-
由 Leif Jurvetson 提交于
-
由 Leif Jurvetson 提交于
-
- 10 3月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 29 2月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 26 2月, 2016 1 次提交
-
-
由 Felix Lange 提交于
Fixes #2201
-
- 23 2月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 22 2月, 2016 1 次提交
-
-
As we aren't really using the standarized SHA-3
-
- 19 2月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 10 2月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 08 2月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 26 1月, 2016 1 次提交
-
-
由 Bas van Kervel 提交于
-
- 04 1月, 2016 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 30 12月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 18 12月, 2015 1 次提交
-
-
由 Felix Lange 提交于
The test chain generated by makeChainFork included invalid uncle headers, crashing the generator during the state commit. The headers were invalid because they used the iteration counter as the block number, even though makeChainFork uses a block with number > 0 as the parent. Fix this by introducing BlockGen.Number, which allows accessing the actual number of the block being generated.
-
- 14 12月, 2015 1 次提交
-
-
由 Bas van Kervel 提交于
-
- 19 11月, 2015 4 次提交
-
-
由 Péter Szilágyi 提交于
-
由 Felix Lange 提交于
-
由 Felix Lange 提交于
State and receipt deliveries from a previous eth/62+ sync can hang if the downloader has moved on to syncing with eth/61. Fix this by also draining the eth/63 channels while waiting for eth/61 data. A nicer solution would be to take care of the channels in a central place, but that would involve a major rewrite.
-
由 Felix Lange 提交于
Unexpected deliveries could block indefinitely if they arrived at the right time. The fix is to ensure that the cancellation channel is always closed when the sync ends, unblocking any deliveries. Also remove the atomic check for whether a sync is currently running because it doesn't help and can be misleading. Cancelling always seems to break the tests though. The downloader spawned d.process whenever new data arrived, making it somewhat hard to track when block processing was actually done. Fix this by running d.process in a dedicated goroutine that is tied to the lifecycle of the sync. d.process gets notified of new work by the queue instead of being invoked all the time. This removes a ton of weird workaround code, including a hairy use of atomic CAS.
-
- 04 11月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 28 10月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 21 10月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 19 10月, 2015 6 次提交
-
-
由 Péter Szilágyi 提交于
-
由 Péter Szilágyi 提交于
-
由 Péter Szilágyi 提交于
-
由 Péter Szilágyi 提交于
-
由 Péter Szilágyi 提交于
-
由 Péter Szilágyi 提交于
-
- 02 10月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-
- 23 9月, 2015 1 次提交
-
-
由 Péter Szilágyi 提交于
-