This approach competes with an easier and more widely used method of running a regular process on an "isolated core", and using "kernel bypass" libraries. On such a system, the process starts up with full access to system resources while it reads config files, allocates, maps, and initializes memory, and sets up devices, and then enters its main loop where it operates solely on memory-mapped buffers and, possibly, I/O registers, running with no system calls or interruptions by the OS, potentially for months after.<p>For example, it might use an OpenOnload library to watch a ring buffer being pushed packets by a NIC via DMA, processing the packets as they appear and updating a mapped/shared memory region with the results. It might, further, construct packet images based on its results, or what it finds in memory mapped from another process, and use the same library to trigger the NIC to send the packet images.<p>Regular, scheduled processes may watch the mapped memory and do less timing-constrained work, such as logging events, performing file system operations, or even operating a UI, and maybe queue requests into more mapped memory polled by the isolated process.<p>This mode of operation is quite common at high-speed stock trading firms, or to control specialized equipment with stringent timing requirements, without need to deploy a realtime OS.<p>Usually these systems make heavy use of ring buffers to keep processes decoupled, placed in "hugetlb" 2MB-sized memory pages to minimize or even eliminate memory-map cache contention, by mapping files in /dev/hugepages.<p>All the regular system facilities still work. The program is built with the ordinary linker. You can attach your regular debugger to the process, at startup or after it has been running for a month.