Native plugins support #154
Conversation
| @@ -131,6 +138,8 @@ impl ProcessState for DefaultProcessState { | |||
| wasi_stderr: None, | |||
| initialized: false, | |||
| registry: self.registry.clone(), | |||
| plugins: self.plugins.clone(), | |||
| plugin_state: HashMap::new(), | |||
There was a problem hiding this comment.
Should we clone the plugin state here? Or put the whole plugin state in an Arc?
The only problem is that we cannot downcast_mut when the state is in an Arc, or even borrow it mutably, and I'm afraid we might need to use mutex's in this case.
| @@ -456,11 +477,31 @@ impl DistributedCtx<LunaticEnvironment> for DefaultProcessState { | |||
| wasi_stderr: None, | |||
| initialized: false, | |||
| registry: Default::default(), // TODO move registry into env? | |||
| plugins: Arc::new(vec![]), | |||
| plugin_state: HashMap::new(), | |||
There was a problem hiding this comment.
Should plugins and plugin state be empty in new_dist_state?
There was a problem hiding this comment.
Probably not (I'm not sure 😄 ), when reading through #69 the original idea was to have different plugins for each Environment.
Testing plugins or comparing performance between competing implementations becomes trivial, just spawn different environments, attach different plugins to them and run the same code.
When spawning via distributed API we use Environment to crate state.
If I understand this correctly calling a function from a dynamic library will fail, in this case when spawning a process on a different node, since plugin is not linked?
|
I just came across an issue, and I'm not sure whats going on.
When I run lunatic in release, everything works fine... but running lunatic in debug mode causes the host functions to silently fail 🤔 It seems like if I compile the wasm plugin and module to debug mode, and run lunatic in debug mode, it works then. |
|
Sorry, it took me a bit longer to get around and check this out. Great work so far! I also can't figure out what the issue with release/debug builds could be. From my understanding on how dynamic loading works, it shouldn't be an issue. It might be something Wasmtime specific, because they do some assembly magic to allow stack switching? Maybe creating a minimal reproducible example with just wasmtime and dynamic loading could help us to pinpoint it. |
Adds support for native plugins (.dll/.so/.dylib) which can be loaded with the
--pluginsflag.An example exists in the
examples/directory, along with some docs on running the example.Related to #69 (nice)