-
Notifications
You must be signed in to change notification settings - Fork 20.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
les: fix private net issues, enable adding peers manually again #3607
Conversation
@zsfelfoldi, thanks for your PR! By analyzing the history of the files in this pull request, we identified @karalabe, @fjl and @obscuren to be potential reviewers. |
88604c7
to
ef799c2
Compare
@@ -663,7 +663,7 @@ func MakeNode(ctx *cli.Context, name, gitCommit string) *node.Node { | |||
Version: vsn, | |||
UserIdent: makeNodeUserIdent(ctx), | |||
NoDiscovery: ctx.GlobalBool(NoDiscoverFlag.Name) || ctx.GlobalBool(LightModeFlag.Name), | |||
DiscoveryV5: ctx.GlobalBool(DiscoveryV5Flag.Name) || ctx.GlobalBool(LightModeFlag.Name) || ctx.GlobalInt(LightServFlag.Name) > 0, | |||
DiscoveryV5: ctx.GlobalBool(DiscoveryV5Flag.Name) || (ctx.GlobalBool(LightModeFlag.Name) || ctx.GlobalInt(LightServFlag.Name) > 0) && !ctx.GlobalBool(NoDiscoverFlag.Name), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this hard to parse for a human brain. Is it possible to reconstruct this statement so it's easier to brain-validate e.g. what effect the NoDiscoverFlag
has on the outcome?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, I shouldn't write expressions like this because it was not exactly what I intended to do :) it's now fixed, reconstructed and clarified.
@@ -173,7 +173,7 @@ func NewProtocolManager(config *params.ChainConfig, fastSync bool, networkId int | |||
return blockchain.CurrentBlock().NumberU64() | |||
} | |||
inserter := func(blocks types.Blocks) (int, error) { | |||
manager.setSynced() // Mark initial sync done on any fetcher import | |||
atomic.StoreUint32(&manager.synced, 1) // Mark initial sync done on any fetcher import |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't hurt to use atomic
here, but I'm curious... Previously, you actually did something if synched
went from 0
to 1
, and thus wanted it to be threadsafe/atomic. Now it seems you could just aswell use non-atomic, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, synced is being read and written in different goroutines, see:
https://github.com/ethereum/go-ethereum/blob/master/eth/handler.go#L663
This is how it worked before I added setSynced (I restored it in its original state).
ef799c2
to
a390ca5
Compare
This PR solves #3510