Stream: git-wasmtime

Topic: wasmtime / PR #7832 Serve guest-profiler results from a l...


view this post on Zulip Wasmtime GitHub notifications bot (Jan 27 2024 at 00:25):

jameysharp opened PR #7832 from jameysharp:profiler-self-serve to bytecodealliance:main:

This is a proof of concept for #7666, but needs quite a bit of polish before merging.

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Jan 27 2024 at 00:30):

jameysharp commented on PR #7832:

If anyone has suggestions on how to do this better I'd be interested to hear them. In particular, I'm not happy with how many crate dependencies I had to add to the Wasmtime CLI to make this work.

Currently this PR reflects just enough hacking together of pieces to prove that #7666 is possible, so I'm not looking for review on small details, just the big picture design questions.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 27 2024 at 01:41):

tschneidereit commented on PR #7832:

An alternative approach that shouldn't introduce any additional runtime dependencies would be to self-host this. I.e., to embed a wasi-http/proxy component that can load the profile from a pre-opened directory and serve it from the incoming-handler.

Such a component should be straightforward to run, and, after stripping, be quite small.


Last updated: Dec 23 2024 at 12:05 UTC