-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow non-global WASI contexts. #331
base: main
Are you sure you want to change the base?
Conversation
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.
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) |
@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! |
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. 🙌🏻 |
Yes I was working on a new thing a bit: |
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:
***@***.***>
|
@vshymanskyy Conflicts resolved. Thanks! |
@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. |
@vshymanskyy: 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):
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? |
Actually, I think it’s not that different … it would just mean removing this PR’s How does that strike you, @vshymanskyy? |
Yes I like it. We can also use explicit |
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? |
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()? |
No, I don't think this has any practical use, i just want to eliminate confusion when switching between implementations. |
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
As best I can tell, the caller won’t care about the version of 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. |
@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. |
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.