Is POSIX Coming to an End? A Historical Review and Future Outlook

Timeline of POSIX abstractions

1970s – Filesystem: open, read, write (V0)

1970s – Processes: fork (V0)

1971 – Processes: exec (V1)

1971 – Virtual memory: brk (V1)

1973 – Pipes: pipe (V3)

1973 – Signals: signal (V4)

1979 – Signals: kill (V7)

1979 – Virtual memory: vfork (3BSD)

1983 – Networking: socket, recv, send (4.2BSD)

1983 – I/O multiplexing: select (4.2BSD)

1983 – Virtual memory: mmap (4.2BSD)

1983 – IPC: msgget, semget, shmget (SRV1)

1987 – I/O multiplexing: poll (SRV3)

1988 – Virtual memory: mmap (SunOS 4.0)

1993 – Asynchronous I/O: aio_submit (POSIX.1b)

1995 – Threads: pthread_create (POSIX.1c)

Evolution of core abstractions

Early Unix abstractions—filesystem, processes, virtual memory, sockets, and threads—were shaped by the hardware of their era (e.g., PDP‑11, VAX) and by workloads such as multi‑programming and batch processing. The end of Dennard scaling (~2004) and the slowdown of Moore's law forced system designers to rely on programmable NICs, specialized accelerators, and non‑volatile memory, exposing limits of the CPU‑centric POSIX model.

Filesystem

The POSIX filesystem abstraction (files, directories, special files, hard and symbolic links) originates from Multics and remains fundamental, but it can become a bottleneck for high‑throughput devices (see [14]‑[17]).

Process model

Processes provide a CPU‑centered execution environment rooted in time‑sharing systems ([18]). Modern accelerators (GPU, TPU, NIC offload) challenge the assumption that computation occurs solely on the CPU.

Virtual memory

Virtual memory offers a large address space independent of physical memory ([20]). It was introduced to run large programs (e.g., Lisp) on machines with limited RAM. The abstraction decouples address space from memory space but is increasingly strained by contemporary workloads that demand direct access to fast storage and accelerators.

Inter‑process communication (IPC)

Signals and pipes were the earliest IPC mechanisms ([2]). BSD added sockets for networked IPC; POSIX later added semaphores, message queues, and shared‑memory interfaces, many of which have been superseded by vendor‑specific solutions ([24]). The mmap interface was once envisioned as an IPC mechanism ([25], [26]) but never achieved wide adoption.

Threads and asynchronous I/O

POSIX threads were introduced in the early 1990s to exploit multicore hardware ([8], [27]). Implementations typically use a 1:1 kernel‑thread model for simplicity ([30], [31]), though other models (N:1, N:M) exist ([27]‑[29]). High‑concurrency frameworks such as SEDA ([32]) and Seastar ([34]) often adopt a one‑thread‑per‑core model to avoid thread‑management overhead ([33], [35]). POSIX asynchronous I/O (AIO) adds non‑blocking I/O system calls but suffers from high overhead: each submission copies up to 104 bytes of descriptors, and calls may block ([38]). Linux’s io_uring , introduced in kernel 5.1, uses two lock‑free single‑producer‑single‑consumer queues to achieve true asynchronous I/O with configurable interrupt‑driven or polling modes ([38]).

Beyond POSIX

Compute offload

POSIX lacks mechanisms to express offloading to GPUs, NICs, or other accelerators. Applications therefore use user‑space APIs such as OpenCL, CUDA, Vulkan, or vendor‑specific libraries to manage memory and resources on these devices ([37]).

Bypassing the POSIX I/O stack

Early examples include the BSD Packet Filter (BPF) which filters packets in a kernel‑resident virtual machine before delivering them to user space ([39]). eBPF extends BPF, allowing sandboxed programs to run in the kernel or on SmartNIC hardware ([40]). Complementary projects such as DPDK and SPDK enable user‑space applications to bypass the kernel for high‑performance network and storage I/O ([41], [42]).

Higher‑level distributed abstractions

Modern services increasingly rely on RPC, HTTP/REST, and managed runtimes that hide underlying POSIX interfaces, further reducing the relevance of low‑level abstractions.

Conclusion

POSIX abstractions were historically driven by hardware constraints and contemporary workloads. Today, the balance between I/O and compute has shifted toward I/O‑bound, accelerator‑rich environments, making many POSIX interfaces suboptimal. The authors argue that the POSIX era is ending and that future operating‑system interfaces must be redesigned to support higher‑level, hardware‑agnostic abstractions beyond the CPU‑centric model.