modify unserializable struct in plugin runtime without global state

[tkkcc]

examples/example-rust-wasmer2-runtime/src/spec/mod.rs gives a way for plugin to modify a host struct using global state. can this be done without global state?

BTW, the example-rust-runtime/spec/mod.rs in readme does't exist.

[arendjr]

Thanks for the heads-up!

What do you mean by modifying a host struct exactly? The global state it is modifying in that example lives within the plugin, so wouldn't affect the host at all.

Could you explain what you would like to achieve?

[tkkcc]

this import function can change value in GLOBAL_STATE. GLOBAL_STATE is init in the runtime code, so i think it is a host value.

fp-bindgen/examples/example-rust-wasmer2-runtime/src/spec/mod.rs

Lines 183 to 190 in 4e95816

	async fn import_increment_global_state() {
	// Possible "race condition", but we don't mind here
	// let val = GLOBAL_STATE.get();
	// GLOBAL_STATE.set(val + 1);
	let mut lock = GLOBAL_STATE.lock().unwrap();
	let value = *lock + 1;
	*lock = value;
	}

the GLOBAL_STATE can also hold an unserializable struct, like a egui context. thus i can let plugin control ui via such import function.

but i want to avoid GLOBAL_STATE style.
here is an example code from mlua. the rust_val is a host value, it can be modified in plugin(lua side). it can be a complex unserializable struct and don't need to be global.

https://github.com/khvzak/mlua/blob/c0c6a33f94127188a528801656effa89387880eb/examples/guided_tour.rs#L195C1-L215C6

    {
        let mut rust_val = 0;


        lua.scope(|scope| {
            // We create a 'sketchy' Lua callback that holds a mutable reference to the variable
            // `rust_val`. Outside of a `Lua::scope` call, this would not be allowed
            // because it could be unsafe.


            lua.globals().set(
                "sketchy",
                scope.create_function_mut(|_, ()| {
                    rust_val = 42;
                    Ok(())
                })?,
            )?;


            lua.load("sketchy()").exec()
        })?;


        assert_eq!(rust_val, 42);
    }

[arendjr]

Oh, you're right, that's my bad. Yes, that one is indeed kept in host memory. Frankly, it's not something we support very well, since the use cases we focus on are more situations where the plugin does things for the host without assuming persistence. Still, I think it's a useful request to consider when we eventually migrate to Wasmer 4.