search

bytecodealliance / wasmtime

A fast and secure runtime for WebAssembly
https://wasmtime.dev/
Apache License 2.0
15.08k stars 1.26k forks source link

support RTOS family in the plan? #420

Open yorkie opened 4 years ago

yorkie commented 4 years ago

The RTOS might be on most low-end device, that would be great if WASI is able to land on those.

It's related with https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md#proc_exit and the multithreading discussion #419, most RTOS platforms do not have child process or threading, we should be careful to include the system interfaces if we want to land those :)

tschneidereit commented 4 years ago

Wasmtime will definitely be an option for these environments, yes. Note that any and all WASI modules will be optional and you'll be able to configure Wasmtime to not include them.

kubkon commented 4 years ago

Heck yeah, RTOS support would be amazing. +10 here! ;-)

yorkie commented 4 years ago

RTOS will not have the process or threading, so we have to flag the related API or impl to user-land, do u guys mind that i create a pr that removes process?

:p

On Wed, Oct 16, 2019, 10:18 PM Jakub Konka notifications@github.com wrote:

Heck yeah, RTOS support would be amazing. +10 here! ;-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CraneStation/wasmtime/issues/420?email_source=notifications&email_token=AAOYTFYIQJOZ25NPDR3K5TLQO4PEFA5CNFSM4JAZ3VJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBMVA7Y#issuecomment-542724223, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOYTF2FZ7Q4JRGGEDLRARDQO4PEFANCNFSM4JAZ3VJA .

tschneidereit commented 4 years ago

Can you explain a bit more what you're proposing to remove exactly? As I said, we'll definitely have the ability to build Wasmtime without all optional features. Multithreading is definitely one of those. And as far as I'm aware, we don't currently have any child processes, so there's nothing to remove.

yorkie commented 4 years ago

What I'm proposed that is:

It might be: __wasi_exit() and __wasi_raise(), and change the "process" to "execution", too. The concept "process" is different on these platforms like: linux, unix and RTOS family.

For example, at FreeRTOS, it only owns itself "execution unit" namely task to replace the process or thread, so what's I'm proposed is to abstract process/task/thread in the wasi layer.

yorkie commented 4 years ago

Can you explain a bit more what you're proposing to remove exactly? As I said, we'll definitely have the ability to build Wasmtime without all optional features. Multithreading is definitely one of those. And as far as I'm aware, we don't currently have any child processes, so there's nothing to remove.

@tschneidereit Optional features answered my question absolutely, the rest is doing port/re-implement the wastime on RTOS, thanks :)

kubkon commented 4 years ago

What I'm proposed that is:

It might be: __wasi_exit() and __wasi_raise(), and change the "process" to "execution", too. The concept "process" is different on these platforms like: linux, unix and RTOS family.

For example, at FreeRTOS, it only owns itself "execution unit" namely task to replace the process or thread, so what's I'm proposed is to abstract process/task/thread in the wasi layer.

A small clarification here. __wasi_proc_raise() is actually meant to be dropped entirely from WASI and hence, we don’t even implement it in wasi-common. As far as __wasi_proc_exit() is concerned, it indeed currently uses std::process::exit() to terminate itself by terminating the process it is running in. I guess, for RTOS, the tricky bit would be to find the equivalent in Rust, but I might be talking crap here so please correct me if I’m wrong. Also, cc @sunfishcode as it might be an interest to you given that we’ve already discussed a little about this and similar use cases offline in the past.

yorkie commented 4 years ago

I googled something related and find this: https://docs.rs/freertos_rs/0.3.0/freertos_rs/, it might be a quick start, however we have to work on abstracting others, too.

sunfishcode commented 4 years ago

I agree that proc_raise doesn't add much value in WASI in its current form and should be removed.

For proc_exit, I expect that when wasm gets exception handling, proc_exit will go away entirely, and we'll instead just use a throw, throwing a non-HLL-catchable exception all the way out to the code that calls the user's main function.

letanphuc commented 1 year ago

Any update on this?