Question: Is wasi3p supposed to include wasi:io/poll?

[KompocikDot]

Hey, first of all, thank you for that project and work you've done!

I've tried to create stripped down component based on your example from examples/http-p3 directory and it works, when called as described in README. The problem is, that when trying to run it with my own code using wasmtime programatically, it returns an error:

component imports instance `wasi:io/poll@0.2.4`, but a matching implementation was not found in the linker

When looking at bindings that were generated by calling componentize-py -d ./wit -w wasi:http/service@0.3.0 bindings app, there is file called poll_loop.py. I'm still a newbie to wasi/wasmtime world, but I suppose that file might somehow be a reason, why that error occurs - it even states that wasi:http@0.3.0 uses different mechanism to model concurrency? Or is that completely my fault?

Part of my wasmtime executor:

let mut wasmtime_config = Config::new();
wasmtime_config.wasm_component_model_async(true);
let engine = Engine::new(&wasmtime_config)?;

let mut linker = Linker::<WASMState>::new(&engine);
wasmtime_wasi_http::p3::add_to_linker(&mut linker)?;

...

[dicej]

Thanks for asking about this, @KompocikDot. The reason componentize-py generates components which imports various WASIp2 interfaces (including wasi:io) is that it embeds a copy of CPython built for WASIp1, and those WASIp1 imports are adapted to WASIp2 imports using the wasi-preview1-component-adapter. The upshot is that the generated components target a WIT world which is the union of the world(s) specified explicitly via the command line interface as well as the set of interfaces imported by the adapter on behalf of CPython.

There's currently no corresponding p1->p3 adapter, so we'll need to wait until CPython supports WASIp3 natively in order to avoid any WASIp2 imports by default.

Note that componentize-py does have a --stub-wasi option (see this example) to replace those imports with trapping stubs, but that only makes sense for components which don't need access to the filesystem, environment variables, random numbers, etc. Also, it wouldn't help in this case because it will stub out all WASI imports, including the WASIp3 ones you explicitly requested (we could probably fix that, though, by distinguishing between imports from the adapter and imports from the application, only stubbing out the former).

The easiest solution in this case would be to call wasmtime_wasi::p2::add_to_linker_async in addition to wasmtime_wasi_http::p3::add_to_linker in your executor, if possible.