mleonhard commented on issue #2274:
I think the new 'fuel' mechanism is sufficient for making wasm threads behave nicely. Thank you.
I found relevant documentation under
wasmtime::Config::async_support
. I wish it did not require async.I found a little issue in the docs:
Care must be taken for this because Wasmtime futures are not
Send
orSync
.The binary
examples/tokio/main.rs
makes a future to callwasmtime::Func::call_async
and passes the future totokio::runtime::Runtime::spawn
which accepts onlySend
futures. If this binary compiles then Wasmtime futures areSend
.Closing issue. Thanks again!
mleonhard closed issue #2274:
I wish to use wasmtime in a server to run small untrusted code blocks. I need to limit the CPU time consumed by each running block. I looked through the docs and found only the ability to interrupt running code (Store::interrupt_handle). I don't want to kill badly-behaved blocks. I want to make the blocks behave nicely. I need the server to run hundreds of wasmtime VMs while also not starving the server's request processing code.
Ideally, wasmtime would let me configure a set of VMs with a shared CPU restriction of a certain number of cores, or fractional cores. The VMs would run concurrently and yield to each other so all can make progress. And all of the VMs in the set would not consume more than the set amount of CPU time per second.
Let's support or document how to restrict instance cpu time.
Related issue for restricting memory usage: #2273
Related discussion: https://users.rust-lang.org/t/limit-handler-to-cpu-memory-bounds/26429
alexcrichton commented on issue #2274:
Thanks for pointing that out, I've updated those docs in https://github.com/bytecodealliance/wasmtime/pull/3034
Last updated: Nov 22 2024 at 16:03 UTC