Asynchronous kernel --> process communication
This feature covers a design and implementation for basically what should replace Windows messages / UNIX signals:
the kernel wants to tell a process about something of interest (e.g. prepare to exit cleanly, you just touched invalid memory, ...).
On UNIX systems these things happen via signals. Puppy does not have signals (and also, signals have funny semantics). Windows handles some of these via messages and UI event loops, other by installing a "structured exception handler". Puppy does not have a UI event loop.
This is a desirable feature as, for example, we start wanting to tear down userspace cleanly on reboot.
Signals have pretty bad ergonomics, mostly due to their entirely asynchronous nature, which means that userspace can do very little safely and must essentially set a flag somewhere and return, hoping that something else is actually going to listen to the flag at a proper safe time.
The hunch here is that the "flag setting" could happen in kernel, and userland just check for it at a safe for it time. Some events do require urgent attention, but those can be handled separately and - to be fair - in most of those cases, getting out fast is probably the best bet the process has anyway. So, this could be split in two:
- a "this can wait" message queue for events that userspace should look at but not right now is fine;
- a "this can't wait" callback that userspace can setup for urgent notifications; this would be akin to a signal with the understanding that there is no generally safe return path from this