expose eager thread-local resource initialization on Engine #2946
Conversation
github-actions
bot
added
cranelift
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "cranelift", "wasmtime:c-api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
|
|
Erm, never mind, I forgot we hadn't merged in the API changes yet, which this is based on. |
There was a problem hiding this comment.
I'm a little wary to do this personally because it feels like we're exposing too many implementation details. For example I think it would be bad if something like a "wasmtime best practices" recommended this. I would personally prefer if we could make the per-thread initialization cheaper if the initialization takes too long, or solve it via some other means.
pchickey
force-pushed
the
pch/eager_per_thread_init
branch
from
200d303
to
ad387f1
Compare
|
That is understandable. We haven't measured, and I don't think signal handler installation takes especially long, but we wanted this functionality so that we could eliminate the possibility from any sort of performance issue we hit at runtime, or debugging any sort of interaction with other parts of the process that install signal handlers. I don't feel extremely strongly about this but @acfoltzer advocated for it, and my judgement was the trouble it might save us debugging one day is worth exposing this implementation detail. |
github-actions
bot
added
the
wasmtime:api
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
Ok, in any case it's a relatively small API and not super hard to support. Could you expand the documentation with some possible use cases though? I'd also prefer if the tokio example didn't get updated to use it because it feels like it's mostly just boilerplate for most use cases and not all that necessary. (although having this in a test seems good) |
| initialized = true; | ||
| } | ||
| p.set((state, initialized)); | ||
| Ok(()) |
There was a problem hiding this comment.
This could probably be a bit simpler with if initialized { return } and then p.set((state, true)) afterwards
pchickey
force-pushed
the
pch/eager_per_thread_init
branch
from
ad387f1
to
bf1d1a4
Compare
crates/wasmtime/src/engine.rs
Outdated
| @@ -63,6 +63,12 @@ impl Engine { | |||
| }) | |||
| } | |||
|
|
|||
| /// Eagerly initialize thread-local functionality shared by all [`Engine`]s. This | |||
| /// will be performed lazily by the runtime if users do not perform it eagerly. | |||
There was a problem hiding this comment.
As a suggestion for a doc block here:
Eagerly initialize thread-local functionality shared by all [
Engine]s.Wasmtime's implementation on some platforms may involve per-thread setup that needs to happen whenever WebAssembly is invoked. This setup can take on the order of a few hundred microseconds, whereas the overhead of calling WebAssembly is otherwise on the order of a few nanoseconds. This setup cost is paid once per-OS-thread. If your application is sensitive to the latencies of WebAssembly function calls, even those that happen first on a thread, then this function can be used to improve the consistency of each call into WebAssembly by explicitly frontloading the cost of the one-time setup per-thread.
Note that this function is not required to be called in any embedding. Wasmtime will automatically initialize thread-local-state as necessary on calls into WebAssembly. This is provided for use cases where the latency of WebAssembly calls are extra-important, which is not necessarily true of all embeddings.
There was a problem hiding this comment.
Thanks! That doc, and the bench docs, are now pushed.
|
yep they were staged in git and i committed wrong. |
Based on #2897 - draft until that lands
In the Tokio runtime and elsewhere, it is useful to eagerly initialize thread-local resources (signal handlers etc) to avoid taking a runtime hit after a service is started.