Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

miner: support multiple custom block collation strategies evaluated concurrently #23383

Closed
wants to merge 26 commits into from

Conversation

jwasinger
Copy link
Contributor

depends on #23256

@jwasinger jwasinger mentioned this pull request Aug 11, 2021
Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot to review here, it's coming along nicely. I'll need to dive more deeply into it later on. Found a few nits though

@@ -0,0 +1,394 @@
// Copyright 2015 The go-ethereum Authors
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Copyright 2015 The go-ethereum Authors
// Copyright 2021 The go-ethereum Authors

)

const (
Uint64Max = 18446744073709551615
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have math.MaxUint64 already

txReceipts = bs.work.env.receipts[startTCount:tcount]
}
// TODO: deep copy the tx receipts here or add a disclaimer to implementors not to modify them?
shouldRevert := cb(err, txReceipts)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had kind of thought that you'd call the cb after each transaction. If you do that, then we might abort earlier, in case there's a sequence of txs in which the first "succeed-fails" (gets into the block but leads to an undesired state, e.g. fails execution).

Any particular reasons for preferring one way over the other? Haven't thought about it too deeply myself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I think calling cb after every transaction makes sense.

Comment on lines 176 to 179
for i := startTCount; i < tcount; i++ {
bs.work.env.txs[i] = nil
bs.work.env.receipts[i] = nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks strange. No need to nil the slice values when you just crop it right below here anyway.

func (m *MultiCollator) Close() {
for _, c := range m.collators {
select {
case c.exitCh <- struct{}{}:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For exit channels, what usually works pretty good is just to close them when it's time to exit. Then it doesn't matter if there's one listening or zero or 100. Whereas if you send a struct{}{}, then you need exactly one listener -- or, do as you've done here, and have a default-case.

So unless you have some compelling reason, just close(c.exitCh) IMO

Comment on lines 334 to 337
select {
case c.newWorkCh <- collatorWork{env: work.copy(), counter: m.counter, interrupt: interrupt}:
m.responsiveCollatorCount++
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a select with only one case -- I think it's equivalent to:

Suggested change
select {
case c.newWorkCh <- collatorWork{env: work.copy(), counter: m.counter, interrupt: interrupt}:
m.responsiveCollatorCount++
}
c.newWorkCh <- collatorWork{env: work.copy(), counter: m.counter, interrupt: interrupt}
m.responsiveCollatorCount++

Is that the intent? Or did you mean to have a default-case too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Missing a default case (shouldn't block when newWorkCh is full).

shouldIgnore := false
for _, finishedCollator := range finishedCollators {
if i == finishedCollator {
shouldIgnore = true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
shouldIgnore = true
shouldIgnore = true
break

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep

@jwasinger jwasinger changed the title miner: support custom block collation strategies miner: support multiple custom block collation strategies evaluated concurrently Aug 19, 2021
@jwasinger
Copy link
Contributor Author

Superseded by #23421

@jwasinger jwasinger closed this Aug 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants