Yorick Peterse (Oct 28 2022 at 22:02): Yorick Peterse (Oct 28 2022 at 22:02):I'm looking at https://github.com/bytecodealliance/wasmtime/blob/main/crates/fiber/src/unix/x86_64.rs to better understand how it switches between fibers. Now my knowledge of assembly is very limited, but on first sight it seems this code doesn't restore RIP. At least, on line 30 in the switch function it _seems_ to do something that might be related, but I'm having a hard time understanding how this updates the instruction pointer.
Yorick Peterse (Oct 28 2022 at 22:03):Basically I have similar code I'm playing around with, and it works fine for starting a fiber and yielding back to the original OS thread/context, but my grug brain can't figure out how to make it work to then be able to resume the fiber. For that I'd have to save RIP, but the various examples I've found (https://github.com/gpderetta/libtask/blob/master/details/switch_base.hpp is another) don't seem to explicitly/clearly handle this
Alex Crichton (Oct 28 2022 at 22:06):The old value of RIP (also known as pc) is stored on the stack for x86_64. Whatever calls wasmtime_fiber_switch will push the return address onto the stack, and that's basically the old value of the pc. The wasmtime_fiber_switch function "returns" but that's actually where the switch completes since the return address is not the same return address as when the function was entered
Yorick Peterse (Oct 28 2022 at 22:09):Ah gotcha, I hadn't thought of the callers being response for saving RIP somewhere :smile:
Lukas Hermann (Oct 31 2022 at 00:09):Hello! I’m not sure if this is the right channel for this question, (and if it’s not feel free to direct me to a place that makes more sense). Lately when browsing rust tooling that is deciding on a plug-in system, people common suggest using wasm as the solution. Usually the threads are accompanied by a suggested script involving WASMTime (hence why I’m asking here). I was hoping to understand what it actually means from an implementation perspective to use wasm for managing plugins. Would that involve spawning a new runtime for each plugin? Or is it more like FFI? I’ve been trying to search around for a blog or wiki page on it but I can’t really find any answers. Thanks :)
code red art (Nov 03 2022 at 08:07):you can make a new thread for your issue. but anyway, here's some references:
https://freemasen.com/blog/wasmer-plugin-pt-1/
https://nullderef.com/blog/plugin-tech/#wasm
basically, you use it just like you use lua. you spawn an embedded runtime, load the wasm binary, call functions from it depending on your usecase. although, I would recommend against webassembly plugins for now. there's a lot of hype and people echoing random generalized statements, but we are not there yet. component-model is still being worked on and meanwhile, you can try joining communities like https://extism.org/ which actually are trying to make the experience smoother.
Last updated: Nov 22 2024 at 16:03 UTC