3 ms·
Wanted to comment the same. When I first learned about memory mapping I went "mmap() all the things!!" since it's so much easier than reads and writes all the t
by iforgotpassword 7y ago
Wanted to comment the same. When I first learned about memory mapping I went "mmap() all the things!!" since it's so much easier than reads and writes all the time, checking for short reads, aligning the pointer and calling read again, handling EINTR, you name it.
But at least you do get proper error codes that you can handle in a somewhat sane way.
A read our write error for an mmapped file? SIGBUS, game over. Want to handle it? Use a signal handler for SIGBUS, use setjmp before every access to your mmapped region and longmp back from your signal handler. And you thought handling all the failure modes of read/write was ugly.
Use mmap if you absolutely need the performance. Otherwise just don't.
- temac 7y agoAnd even then mmap does not guarantee performance. So for example just don't use mmap for small files, and for larger ones benchmark to see if you really get some perf. As for the code, if you just can let it crash, prefer that to attempting to handle it, because this kind of handling is even worse to test and debug than normal error code paths.
- icedchai 7y agoBack almost 20 years ago, I worked on a medium-sized system - 1000's of simultaneous users, millions in $USD transactions daily - that was based on an mmap'ed flat file "database." It worked amazingly well. (Note that we did none of that sort of error handling!)
- todd8 7y agoYes, the first time I saw this described was in 1987 in a paper by A. Birrell, et. al. See [1]. It was also available as a DEC SRC report, number 24. [1] A simple and efficient implementation of a small database, https://dl.acm.org/doi/abs/10.1145/37499.37517?download=true https://dl.acm.org/doi/abs/10.1145/37499.37517?download=true