|
|
|
|
|
|
by mananaysiempre
1113 days ago
|
|
|
Plain fork (as opposed to vfork) isn’t really error-prone, it’s arguably less error-prone than threads. (It forces bad resource accounting, like most CoW mechanisms, but that’s an orthogonal issue.) Signals and setjmp... have their problems, admittedly, but on a restricted VM like WASM are AFAICT unimplementable on top of other things. So if you want unwinding, you’ve got to have an equivalent to setjmp (or throw / catch) if you want asynchronous interrupts, you’ve got to have an equivalent to signals. |
|
|
Unwinding is a somewhat cleaner interface than setjmp/longjmp, and it's a useful primitive in its own right, especially if you can attach a notion of a stack trace to the unwind primitive. At a low-level language primitive level, unwind can be seen essentially as a combination of a mechanism to have two distinct exit points from a function call (the normal and exceptional return addresses) and an intrinsic that causes the function to return via its exceptional return address instead of the normal return address.
> if you want asynchronous interrupts, you’ve got to have an equivalent to signals.
... not really. There's a few different kind of signals. Synchronous processor signals (e.g., SIGSEGV, SIGFPE) could be supported via something akin to unwind rather than signal handlers (and this is essentially how they work on Windows). The asynchronous events can instead be supported by basically having some primitive notion of an event loop, dropping those signals as events in the event loop. Signals already interoperate pretty sketchily with event loops, and many signal handlers for asynchronous events already tend to boil down to "just dump this as an event in the event loop", so you're left with a pretty sketchy work around to do what you actually wanted to do.
Interfaces like fork and POSIX signals are pretty notorious for being generally wrong ways to do what you actually wanted to do; if you're making a new OS ABI, there's absolutely no reason to include them, especially because they can be hard to emulate on some OSes, e.g., Windows or Fuchsia (which lacks POSIX signals altogether).