TransactionScheduler: SchedulerController #33825
Conversation
|
I had forgotten that this PR was necessary before the piping PR. Next PR before the scheduler can be used on master would be piping of CLI & spawning the worker/scheduler threads. |
apfitzge
force-pushed
the
scheduler_controller
branch
from
a55d695
to
a3e0ffb
Compare
Codecov Report
@@ Coverage Diff @@
## master #33825 +/- ##
========================================
Coverage 81.8% 81.9%
========================================
Files 809 810 +1
Lines 217643 217961 +318
========================================
+ Hits 178247 178592 +345
+ Misses 39396 39369 -27 |
core/src/banking_stage/transaction_scheduler/scheduler_controller.rs
Outdated
Show resolved
Hide resolved
core/src/banking_stage/transaction_scheduler/scheduler_controller.rs
Outdated
Show resolved
Hide resolved
core/src/banking_stage/transaction_scheduler/scheduler_controller.rs
Outdated
Show resolved
Hide resolved
| ) -> Result<(), SchedulerError> { | ||
| match decision { | ||
| BufferedPacketsDecision::Consume(_bank_start) => { | ||
| let _num_scheduled = self.scheduler.schedule(&mut self.container)?; |
There was a problem hiding this comment.
A slight change of behave here. Currently buffered packets are immediately consumed after decision; here there will be some delay between being scheduled and being picked up by worker thread for processing. Don't know the implication with additional hop, just want to point it out
There was a problem hiding this comment.
Yeah I think there's a distinction between the two, i.e. scheduled (queued) for consuming vs immediately consuming.
There was a problem hiding this comment.
Yeah I think there's a distinction between the two, i.e. scheduled (queued) for consuming vs immediately consuming.
apfitzge
changed the title
|
noooooo |
|
back to rebase hell 😭 |
Problem
Need control-flow for packet receiving & scheduler.
Summary of Changes
SchedulerControllerthat is the main interface for the scheduling threadFixes #