Use mmap with care
There&#x27;s also the matter of taking an implicit &quot;system call&quot; (via page fault) the first time your program touches a page that hasn&#x27;t yet been faulted. This old myth that mmap is the fast and efficient way to do IO just won&#x27;t die. mmap does have perfectly legitimate use cases (e.g., reducing anonymous commit charge) but you should try to make regular reads work first.<p><i>That said</i>, there&#x27;s nothing wrong with mmap or SIGBUS error reporting in concept. I think I&#x27;ve said it before, but you can think of mmap of a disk file as basically adding a temporary dedicated swap file to the system, with all the pages backed by that &quot;swap file&quot; already &quot;swapped&quot; out unless already cached. Sometimes that&#x27;s exactly what you want!<p>The author&#x27;s signal handler registration difficulties come from the POSIX signal API being awful, not from the idea that catching CPU traps is somehow bad. It&#x27;s possible to do much better than sigaction(2). I wrote up a detailed proposal for improvement in [1].<p>When I ran [1] by the glibc people, though, the response from them was pretty stark and unwarranted hostility toward any use of signals at all, even in perfectly legitimate scenarios, like mmap SIGBUS or certain kinds of important JVM-style pointer check [2] optimizations. It&#x27;s this &quot;we won&#x27;t change anything anywhere despite our views being out of step with real user needs&quot; attitude that&#x27;s responsible for a lot of weird friction in the Unix API surface.<p>Practically every program mmaps disk files has trouble recovering from IO errors. If it were easier for multiple components in a process to share responsibility for handling a signal, we&#x27;d more often get subtleties like this right. A better signal API will improve the user experience. Tilting at signal-shaped windmills won&#x27;t.<p>[1] <a href="https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;daniel-colascione&#x2F;toward-shareable-posix-signals&#x2F;10157129032641102&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.facebook.com&#x2F;notes&#x2F;daniel-colascione&#x2F;toward-shar...</a><p>[2] Relying on CPU traps lets you perform certain checks for free. Why write &quot;if (myptr != nullptr) var = <i>myptr&quot; when you can just write &quot;var = </i>myptr&quot; and handle the SIGSEGV when myptr ends up being nullptr? The latter option is zero-overhead in the non-nullptr case. It&#x27;s also much more complicated, but if you&#x27;re a VM, and you generate <i>millions</i> and <i>millions</i> of these &quot;if (myptr != nullptr)&quot; checks in JITed code, the size and speed win of eliminating the check starts to justify the complexity.