Allow non-global WASI contexts.

[FGasper]

This allows embedding applications to create multiple WASI instances
within the same process. It preserves the existing singleton
implementations while allowing the newer path.

The new interfaces are prototyped in m3_api_wasi.h.

[sascha1337]

this looks rocksolid, @vshymanskyy hope you okay - seems like there's no maintenance on this repo anymore, at all - how to progress on this one ? LGTM x)

[vshymanskyy]

@sascha1337 sorry, I've been busy lately. But I do see wasm3 needs some attention! I'll try to allocate some time during the following weeks!

[sascha1337]

Was it in any way related to something new, tech-wise? If so, let us know what you have been cooking - but if in case it was due to the geopolitic sadness and family, ( I saw the tweet. Heartbreaking), may god bless you and all related, no problem at all, that things go first. 🙌🏻

[vshymanskyy]

Yes I was working on a new thing a bit:
https://github.com/vshymanskyy/muon
But mostly earning money. We need them 😁

[sascha1337]

Fire! i'm curious, how it performs against mostly used protobuf / gRPC stuff - especially for embedded, this could be gold for sure. but - im not a fan of python sadly, i would celebrate and promote this new lib as much as possible, if there would be some typescript or better RUST/golang impl for this one : ) Lets go ! Am So., 28. Aug. 2022 um 04:53 Uhr schrieb Volodymyr Shymanskyy < ***@***.***>:

…

Yes I was working on a new thing a bit: https://github.com/vshymanskyy/muon But mostly earning money. We need them 😁 — Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6MWVPA5FLDHZJHPXSFRJ3V3J533ANCNFSM5T5GDSCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[FGasper]

@vshymanskyy Conflicts resolved. Thanks!

[vshymanskyy]

@FGasper adding WASI-specific functionality to the Module API is not ideal: in fact WASI should be completely separated from the wasm3 engine, but this wasn't done yet.
I think maybe we should switch to using m3_LinkRawFunctionEx for all uvwasi bindings and pass uvwasi instance via the userdata? This would also play nicely with metawasi (which can be left unchanged in this case). WDYT?

[FGasper]

adding WASI-specific functionality to the Module API is not ideal: in fact WASI should be completely separated from the wasm3 engine, but this wasn't done yet. I think maybe we should switch to using m3_LinkRawFunctionEx for all uvwasi bindings and pass uvwasi instance via the userdata? This would also play nicely with metawasi (which can be left unchanged in this case). WDYT?

@vshymanskyy: m3_LinkWASI seems already to be WASI-specific functionality in the Module API, though I get the desire to avoid furthering that design, and at the least it’s not “teaching” the module internals about WASI.

If I understand correctly, you envision a WASI object—assumedly this could be uvwasi, wasm3’s own WASI, or something else—that fulfills the m3_module’s needed imports, without the m3_module knowing or caring that the imports are WASI.

So something like (pseudocode):

wasi_context = m3_AllocStruct(m3_wasi_context_t);
m3_LinkCustomWASI(module, wasi_context);

That’s probably a cleaner design in terms of looser coupling. Applications would just need to take care to free the WASI and m3_module together. It also seems like a more significant API design change, though maybe not by much?

[FGasper]

Actually, I think it’s not that different … it would just mean removing this PR’s struct M3Module.wasi, and adjusting code accordingly. m3_GetModuleWasiContext would go away, and I’d probably rename m3_LinkModuleWASI to m3_LinkCustomWASI. Applications would just have to ensure that that “custom” WASI-context gets freed along with the M3Module.

How does that strike you, @vshymanskyy?

[vshymanskyy]

Yes I like it. We can also use explicit m3_LinkUvWASI / m3_LinkMetaWASI / m3_LinkSimpleWASI (and maybe even split the header in future). Only UvWASI can have multiple instances at the moment.

[FGasper]

Only UvWASI can have multiple instances at the moment.

Why is that? I see that only UvWASI can accept configuration options, but can’t there be multiple simple-WASI instances that all just access the same host OS resources?

[FGasper]

We can also use explicit m3_LinkUvWASI / m3_LinkMetaWASI / m3_LinkSimpleWASI (and maybe even split the header in future).

From what I can tell, the WASI implementation is determined when wasm3 is built. Are you thinking that, for example, a UvWASI-built wasm3 would expose both m3_LinkUvWASI() and m3_LinkSimpleWASI()?

[vshymanskyy]

No, I don't think this has any practical use, i just want to eliminate confusion when switching between implementations.
Esp. as those methods will have different signatures (or expect a different version of m3_wasi_context_t)

[FGasper]

I’ve pushed an update that reworks the branch a bit. I’ve not actually tested it, though I’m curious of your thoughts: 1ae165d

i just want to eliminate confusion when switching between implementations.

As best I can tell, the caller won’t care about the version of m3_wasi_context_t, and making the WASI API differ depending on the WASI implementation would make it harder to swap out the WASI implementation.

For example, in my Perl binding, right now I use UvWASI on platforms that I’ve seen support it, and simple WASI elsewhere. It’s nice that the WASI interaction code is the same regardless of the WASI implementation.

[vshymanskyy]

@FGasper sorry for the huge delay. I decided to perform a maintenance release of wasm3, so I hope to review and merge PRs like this finally.