11–20 of 48 posts
TFA says "By mmap'ing a region and then accessing into it, the overhead of creating multitudes of small interlinked items can be reduced hugely." You do not need to call mmap directly, because malloc() will do it if your allocation exceeds MMAP_THRESHOLD (usually on the order of a megabyte). So you get this optimization "for free"--the only important part is that you do not call malloc() for each tiny object.
This is basically used for this little gem: http://symas.com/mdb/ LMDB is at the heart of the ubiquitous LDAP ( OpenLDAP ) and is very well optimized ( look at his benchmarks ). Now they are optimized for reading, which is important. I would imagine mmap-ing with large amount of write will result in unpredictable performance....
For more general use, a simple way to keep the amount of 'pending writes' down to reasonable levels is to have a thread walking your mmap()'d regions and enforcing an msync() on a regular basis. This also gives you guarantees such as "each part of mmap'd file is no more than N seconds out of date".
Of course, you'll potentially increase disk load overall, since a page dirtied three times, once every second, might only get written out once by the kernel (after 5s) but if you're syncing every 1s it'll get written three times.
But you should be able to take control.
This give string,set,map,list,deque,vector types that work in the shared space.
http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/a...
It's not that your program crashes, it's that your memory becomes corrupt and that causes the crash.
Restarting program is essentially redoing all the memory. If you persist your memory your program will crash on run.
"explicitly choosing a file and mapping that into the memory space of the program means it can persist across crashes" It's not that your program crashes, it's that your memory becomes corrupt and that causes the crash. Restarting program is essentially redoing all the memory. If you persist your memory your program will crash on run.
The mmapped files are going to break every time you make the smallest change to your data structures. This strikes me as not terribly useful for rapid development.
For a while I've wanted a nice C library for an mmapped heap with allocation and common data structures (and maybe locks?) - all the usual stuff you'd expect in a standard library, but with support for relative offsets instead of pointers, crash robustness, introspection, and other features required to work well with a persistent file. I do not know any library of this type that currently exists.