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

Remove EngineGetter #247

Merged
merged 1 commit into from
Aug 17, 2023
Merged

Conversation

jprendes
Copy link
Collaborator

This PR removes the EngineGetter trait and replaces it with the use of Default::default().
In the case where an instance would have implemented a non-trivial EngineGetter, there are two options:

  • If the associated Engine type is local to the crate, implement a suitable Default.
  • Otherwise, use a wrapper struct for the associated Engine type and implement a suitable Default for the wrapper (and optionally also Deref)

Signed-off-by: Jorge Prendes <[email protected]>
@jprendes jprendes requested review from Mossaka and cpuguy83 August 17, 2023 19:06
@jprendes
Copy link
Collaborator Author

@cpuguy83 , I know you had concerns with removing EngingeGetter in #231 (comment). Would this be acceptable?

Comment on lines -139 to -160
impl EngineGetter for Wasi {
type Engine = Vm;
fn new_engine() -> Result<Vm, Error> {
PluginManager::load(None).unwrap();
let mut host_options = HostRegistrationConfigOptions::default();
host_options = host_options.wasi(true);
#[cfg(all(target_os = "linux", feature = "wasi_nn", target_arch = "x86_64"))]
{
host_options = host_options.wasi_nn(true);
}
let config = ConfigBuilder::new(CommonConfigOptions::default())
.with_host_registration_config(host_options)
.build()
.map_err(anyhow::Error::msg)?;
let vm = VmBuilder::new()
.with_config(config)
.build()
.map_err(anyhow::Error::msg)?;

Ok(vm)
}
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a red herring.
It's actually never used, the WasmEdgeExecutor builds its own Vm from scratch.

Copy link
Member

Choose a reason for hiding this comment

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

Oh I guess this answers my questions

Copy link
Member

Choose a reason for hiding this comment

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

Should we build Vm in the instance and then passes it to Executor so that we enable sharing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe.
I didn't share in this PR because the code here (removed) and the one in the executor were different, and wasn't sure the vm in the executor was shareable (it does things like installing plugins).
@CaptainVincent , do you have any input?

Copy link
Contributor

Choose a reason for hiding this comment

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

From my memory, it was used before the refactor into the container/executor architecture, but the current structure indeed always creates a new one. The aspects of sharing and reusing also involve the implementation's support for wasm runtime context. I thought enabling instance sharing only at the shim level might be questionable. I think there shouldn't be an issue removing it at this point.

Copy link
Member

@Mossaka Mossaka left a comment

Choose a reason for hiding this comment

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

LGTM! Had some questions on the WasmEdge shim.

@cpuguy83 cpuguy83 merged commit b244128 into containerd:main Aug 17, 2023
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.

4 participants