design
design copied to clipboard
WebAssembly
Pre-proposal: Interrupt handling
This might sound rather strange, and possibly ill-suited to WebAssembly, but I could imagine certain embedders actually wanting to support it. Browsers probably wouldn’t.
The basic idea is to provide a way to handle a callback from an embedder that may happen at any CPU (not WebAssembly!) instruction boundary. The classic examples of this are hardware interrupts and Unix signals.
This came up recently on an issue in the WASI repo it was mentioned that linux has signalfd(): https://man7.org/linux/man-pages/man2/signalfd.2.html. How many of the use cases you have in mind do you think could be handled adding something like that at the WASI level? It avoids the whole preemption issue, and allows application to effectively poll/wait for signal events.
This came up recently on an issue in the WASI repo it was mentioned that linux has signalfd(): https://man7.org/linux/man-pages/man2/signalfd.2.html. How many of the use cases you have in mind do you think could be handled adding something like that at the WASI level? It avoids the whole preemption issue, and allows application to effectively poll/wait for signal events.
signalfd() on Linux, and EVFILT_SIGNAL on the BSDs, are a much better solution for Unix signals. I suspect illumos event ports also have a mechanism for this, and if nothing else the self-pipe trick works on all Unix systems. That isn’t sufficient for preemption, though, and there are actually applications that want that (usually for context switching). Go, for example, switched from cooperative to preemptive goroutine scheduling.
@sbc100 good point and i agree and Fuchsia OS as a whole does also use that with good results. in Fuchsia there are Only Jobs/Tasks and Processes. Overall my experience with that scheduling is well
There's some discussion related to this issue in https://github.com/WebAssembly/design/issues/1459#issuecomment-1308860343 and preceding comments.
@RossTate I am not sure if those approaches would be sufficient for this pre-proposal, which is mostly aimed at OS kernels and embedded systems. In this case it may be necessary to do something in the interrupt, such as acknowledge it so that the hardware deasserts the interrupt line (assuming level-triggered interrupts).
Sorry, didn't mean to imply they solved the problem! Just pointing to some challenges on both specifying and implementing a related problem, in case it offered some shortcuts.
the gc linear memory root marking is interesting for wasm i already run net wide memory grids in the browser based on concept of persistent loaded memory and throwing away like gc what is not loaded i designed a new kind of ffi to make that hapen where i do not do ffi i throw in a empty context and use it like shared memory let the function do its thing on the context directly so like working with handels and do not transfer data that leads to a net wide in memory grid program able via import export operators in ECMAScript i call that web 4.0 as it does not need html
My final conclusion is this should not get added we should use Streams over a file handle if we want to link directly from linux or a posix compatible signal i did check the current state of posix signals in a variation of kernel implementations mainly the compat between linux bsd mach(macos) (iridium win11) it makes no sense to take the signals as given by default wasm does not run on a posix environment by default.
Streams do solve efficient wait locking mutex futex stuff in a nice way you do not even need code any logic for that.
@frank-dspeed: I agree when it comes to signal handling, but this does not work for preemptive context switching.