The big problem with mmap seems to be handling I/O errors. The most transparent uses of mmap are for executables. Failing to page in part of the program can probably reasonably result in a crash. But what of a server process handling a pile of different data on unreliable disks? Destroying the entire process on a single I/O error isn't ideal.
On Windows it seems like the best way to handle these errors is by either embedding SEH into the surrounding code or adding a vectored exception handler globally. On Unix, you have to set a SIGBUS signal handler. But then, mmap is apparently not guaranteed to be async-signal-safe if you want to remap a zero page over the broken one, and longjmp out of a signal handler is its own pile of potatoes; both seem to work on various modern Unixoids, but I haven't been able to find documentation saying that they'll continue to work. And with longjmp, or on Windows (where you can't remap pages over other pages directly, that I know of), any surrounding code that accesses the map needs to be abortable all the way up to a suitable error point rather than just having to handle bogus values. Much code assumes that a simple memory access will not cause a recoverable exception that may result in reëntering the code later.
And if you're in a library on Unix, good luck getting permission from the main process to alter signal handlers. The hook mechanism isn't as rich as that in Windows, so with the exception of large application framework libraries that are expected to take over the process anyway, it's an invasive and possibly irreversible activity.
This is all sad, because I love the idea of mmap. I was tinkering with a C library for accessing certain kinds of files, and I want to do it with all mmap, but I'm not sure I can overcome the I/O error problem adequately. (The blocking and address space problems are not too bad here; they impact performance and capacity, but not correctness.)
On top of all of that, using mapped I/O effectively means embracing it directly. Adding an abstraction layer on-top that would allow a quick switch to stdio would negate the benefits. Sucks.
On Windows it seems like the best way to handle these errors is by either embedding SEH into the surrounding code or adding a vectored exception handler globally. On Unix, you have to set a SIGBUS signal handler. But then, mmap is apparently not guaranteed to be async-signal-safe if you want to remap a zero page over the broken one, and longjmp out of a signal handler is its own pile of potatoes; both seem to work on various modern Unixoids, but I haven't been able to find documentation saying that they'll continue to work. And with longjmp, or on Windows (where you can't remap pages over other pages directly, that I know of), any surrounding code that accesses the map needs to be abortable all the way up to a suitable error point rather than just having to handle bogus values. Much code assumes that a simple memory access will not cause a recoverable exception that may result in reëntering the code later.
And if you're in a library on Unix, good luck getting permission from the main process to alter signal handlers. The hook mechanism isn't as rich as that in Windows, so with the exception of large application framework libraries that are expected to take over the process anyway, it's an invasive and possibly irreversible activity.
This is all sad, because I love the idea of mmap. I was tinkering with a C library for accessing certain kinds of files, and I want to do it with all mmap, but I'm not sure I can overcome the I/O error problem adequately. (The blocking and address space problems are not too bad here; they impact performance and capacity, but not correctness.)