There isn't exactly a shortage of examples where mmap() was in the short-term quite convenient to get to market quickly with something Good Enough to appear pro

There isn't exactly a shortage of examples where mmap() was in the short-term quite convenient to get to market quickly with something Good Enough to appear production ready, that in the long-term proved to be rather problematic. Mongodb's original mmap storage engine (32-bit support anyone?), ultimately required replacement (wiredtiger was purchased in part for this reason IIRC). systemd-journald read side (journalctl, `systemctl status`, sd-journal API), performance/scalability definitely suffers from the decision to use mmap for all IO. mmap IO is extremely seductive in terms of programming style/convenience as it facilitates writing procedural, IO-naive code that assumes file-backed memory accesses Just Work. But this is transparently blocking, synchronous code. Since your program isn't explicitly scheduling IO and continuations for execution upon completion of IO, there's zero application-level IO parallelism. The only asynchronous IO possible is what the kernel can automagically perform using relatively dumb page fault heuristics and madvise() hints. When your process triggers a major fault on an mmap region, everything comes to a grinding hault; no speculative execution past that point, no potential for triggering other page faults in other files or independent regions of the same file, it all stops until the data is read from the backing store. Not without the use of threads, which brings a host of other issues.