Avoid realtime clock and immediate-timer imports while the preview1 adapter is paused - #14319
carsonfarmer wants to merge 1 commit into
Conversation
…pter Extend the existing allocation-time clock pause to realtime reads and a single immediate relative-clock poll. Preserve normal unpaused calls and reject other paused polls. Verify clock pause/resume and immediate-event behavior with deterministic host clocks. Co-authored-by: Codex <noreply@openai.com>
dicej
left a comment
There was a problem hiding this comment.
Thanks, @carsonfarmer !
Like Alex mentioned on the previous PR, I don't love that we're bending over backwards to accommodate the Go runtime in an otherwise general-purpose tool, plus this tool was meant to be a temporary thing from the beginning, so it doesn't feel great to be adding new features to it. Eventually, I expect we'll want to move this kind of thing to componentize-go, but for now this is probably the path of least resistance.
|
@dicej Definitely open to hosting a custom adapter for componentize-go. At what point would it make sense for us to do this? |
Totally fair @dicej, I did try to avoid patching at the wasmtime layer, but couldn't find a cleaner solution. To be honest, there is a lot more clock reading in normal Go runtime than I would have imagined 🫤! I have a working solution on my end, so there is no actual rush here for me. Happy to defer to a broader discussion about where something like this should ultimately live? |
|
@ricochet pursued an alternative approach that would avoid any accommodations in the adapter. |
Go GC can read wall time and poll timers during
cabi_realloc, where host calls are forbidden. Extend the pause added in #13563 to cache realtime reads and answer a single immediate timer poll without calling the host. Other paused polls returnNOTSUP.Adds clock and timer tests; the Go regression passes with the fix on Go 1.26.3 and 1.27.1.
Fixes #14318.