Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Orchestrator Async runtime improvements #274
Orchestrator Async runtime improvements #274
Changes from 3 commits
6e88e25
c7fffc3
87996fc
bf0ed0a
b403dea
71d4acb
3ef27eb
763fd16
b5faf34
9347dde
cab25b2
fc227ac
14ddc5c
4d7cc8f
17d6d54
81c152c
165f569
acf20ea
d2dd8d2
b79a083
9b958a3
268d995
a6cb54a
1a15f8e
df1c1a3
ab2bca6
19c9eee
d5f6ebc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
In the old version of this loop, we could fail faster (in this case only waiting
DELAY
instead ofETH_ORACLE_LOOP_SPEED
) and try from the beginning of the loop again. In the tokiojoin!
model we'll always wait the fullETH_ORACLE_LOOP_SPEED
before starting again. I know that the task joining model was suggested by the auditor, and it is cleaner, but probably performs worse in cases where we'd rather restart the loop. Based on the comments at the bottom around the elapsed time calculation, we might care more about performance than wall clock consistency.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.
@cbrit, the problem here isn't
sleep
, rather it'sjoin
. Withjoin
, we have to wait the fullETH_ORACLE_LOOP_SPEED
before starting again. However, the previous code hadcontinue
.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.
@hannydevelop I know. I am suggesting that
interval
might be a better solution thanjoin
because it allows us tocontinue
the loop while still making sure the loop only runs everyETH_ORACLE_LOOP_SPEED
seconds if thematch
is a successful case.The auditor said
but this is solved by
interval
.As far as performance, I am not sure how it differs from
join
, or how much it really matters.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.
In my opinion, I'll rather use
timeout
andsleep
or return back to usingInstant::now
. Let's discuss this on Monday, I can try to contact the auditor for the logic behind usingjoin
inmain_loop