Skip to content

refactor: Revisit Scheduler's public API #4870

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

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

xxuejie
Copy link
Collaborator

@xxuejie xxuejie commented Apr 9, 2025

Previous code marks all fields in the Scheduler structure as public, while at the same time expose enough function to build a debugger. However, by looking at the expose APIs and their docs, one cannot have a clear picture of how to interact with a Scheduler, if they don't read the whole implementation in full.

This change aims at exposing enough public APIs of the Scheduler structure, enabling as much outside usage as possible, while at the same time also maintaining a sane view of the Scheduler structure.

What problem does this PR solve?

Issue Number: close #xxx

Problem Summary:

What is changed and how it works?

Proposal: xxx

What's Changed:

Related changes

  • PR to update owner/repo:
  • Need to cherry-pick to the release branch

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code ci-runs-only: [ quick_checks,linters ]

Side effects

  • Performance regression
  • Breaking backward compatibility

Release note

None: Exclude this PR from the release note.
Title Only: Include only the PR title in the release note.
Note: Add a note under the PR title in the release note.

Previous code marks all fields in the Scheduler structure as public,
while at the same time expose enough function to build a debugger.
However, by looking at the expose APIs and their docs, one cannot have a
clear picture of how to interact with a Scheduler, if they don't read
the whole implementation in full.

This change aims at exposing enough public APIs of the Scheduler
structure, enabling as much outside usage as possible, while at the same
time also maintaining a sane view of the Scheduler structure.
@xxuejie xxuejie requested a review from a team as a code owner April 9, 2025 06:08
@xxuejie xxuejie requested review from doitian and quake and removed request for a team April 9, 2025 06:08
@xxuejie
Copy link
Collaborator Author

xxuejie commented Apr 9, 2025

cc @mohanson

@eval-exec eval-exec requested a review from Copilot April 9, 2025 07:03
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

script/src/scheduler.rs:964

  • [nitpick] Since boot_vm has been converted from a public API to an internal helper, consider renaming it (e.g., _boot_vm) to clearly indicate its internal usage.
fn boot_vm(&mut self, location: &DataLocation, args: VmArgs) -> Result<VmId, Error> {

@@ -138,13 +139,50 @@ where
}
}

/// If current scheduler is terminated
pub fn terminated(&self) -> bool {
self.states[&ROOT_VM_ID] == VmState::Terminated
Copy link
Preview

Copilot AI Apr 9, 2025

Choose a reason for hiding this comment

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

Direct indexing into self.states may panic if ROOT_VM_ID is unexpectedly missing. Consider using a safe accessor like get() with proper error handling.

Suggested change
self.states[&ROOT_VM_ID] == VmState::Terminated
match self.states.get(&ROOT_VM_ID) {
Some(state) => *state == VmState::Terminated,
None => false, // Return false if ROOT_VM_ID is missing
}

Copilot uses AI. Check for mistakes.

});
}

let (id, _) = self.iterate_outer(&Pause::new(), u64::MAX)?;
Copy link
Collaborator

@eval-exec eval-exec Apr 9, 2025

Choose a reason for hiding this comment

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

If self.terminated() is false, should we return the remaining_cycles from self.iterate_outer(&Pause::new(), u64::MAX)?; to exit_status?
Probably not, because IterationResult::exit_status.1 is intended to store the consumed_cycles, not the remaining_cycles?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

IterationResult::exit_status.1 should always contain consumed cycles up to the execution point.

@eval-exec eval-exec added t:enhancement Type: Feature, refactoring. m:vm labels Apr 9, 2025
/// VM ID that gets executed
pub executed_vm: VmId,
/// Exit status
pub exit_status: Option<(i8, Cycle)>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggest add code comment for Cycle:

    pub exit_status: Option<(i8, /*! consumed_cyles */ Cycle)>,

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I actually split a separate type to better indicate usage.

@@ -774,6 +835,16 @@ where
Ok(())
}

fn terminated_result(&mut self) -> Result<(i8, Cycle), Error> {
assert_eq!(self.states[&ROOT_VM_ID], VmState::Terminated);
Copy link
Collaborator

@eval-exec eval-exec Apr 9, 2025

Choose a reason for hiding this comment

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

How about reuse assert!(self.terminated()); and move this method to be adjacent to pub fn terminated(&self) -> bool since they are both related to termination.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done

eval-exec
eval-exec previously approved these changes Apr 9, 2025
eval-exec
eval-exec previously approved these changes Apr 9, 2025
zhangsoledad
zhangsoledad previously approved these changes Apr 10, 2025
@xxuejie
Copy link
Collaborator Author

xxuejie commented Apr 10, 2025

Please hold this for now, I'm addressing a potential bug in a tool that relies on this change. Chances are the public APIs are not designed good enough.

The bug should be resolved by now. Feel free to review the updated PR.

@xxuejie xxuejie dismissed stale reviews from zhangsoledad and eval-exec via ac4b624 April 10, 2025 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
m:vm t:enhancement Type: Feature, refactoring.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants