Philipp Tessenow

closing this for now in an attempt to clean up old issues. feel free to (re-) open an issue if things change

I'm really late to the party (sorry!) but what if `wasmex` becomes an interface + tooling package that then has sub-dependencies (`wasmex-wasmer`, `wasmex-wasmedge`, ..) for actual execution? These sub-dependencies would...

cool, so let me think some shower thoughts out loud. I would be very interested in your thoughts too (but see that you might not be too much into wasmex...

As discussed [here](https://github.com/tessi/wasmex/issues/336) I am in the process of rewriting wasmex to wasmtime as an exercise to see how different the different WASM engines can be and where wasmex needs...

Closing this in favour of #336 Thanks for all the input, everyone! ❤️

Thanks for asking! 💜 I would love to have wasmtime as the first other engine. I even have a local (currently not working) fork porting wasmex to wasmtime - I...

Hey @brooksmtownsend 👋 sorry for letting you hang so long. But I have mildly good news for a wasmtime fork of wasmex. I used some of my vacation time to...

Regarding the store-deadlock problem, I just realized that our wrapped functions receive a [Caller](https://github.com/bytecodealliance/wasmtime/blob/ca3947911eebeadc2f5f0dfeedb9e2357d9231f1/crates/wasmtime/src/func.rs#L1495) which happens to implement `AsContextMut`/`AsContext` and can act like a `Store` when called within the function...

Maybe we can get inspiration from wasmtime-py, they interface the C API, but they do exactly what I proposed above. [They take the caller and pass them as a reference...

no worries. I'm in the same boat :)