4 ms·
Thinking out loud: Since handles refer to offer rather than absolute addresses, this sort of scheme should allow for "serializing" data by memmapping chunks of
by wtracy 6y ago
Thinking out loud:
Since handles refer to offer rather than absolute addresses, this sort of scheme should allow for "serializing" data by memmapping chunks of memory to disk.
Obviously, this scheme wouldn't be useful for cross-platform save files, and might not even translate across builds.
Still, as long as you have a robust scheme for invalidating data when a new version is deployed, I could see this being useful for caching, and for saving state for short periods of time on mobile platforms that like to restart processes with little warning. (Rather than potentially losing your place within the game level any time you switch between apps, you only lose your place within the game level when an app update gets installed.)
- bluetomcat 6y agoHandles are essentially integer indexes, relative to a base pointer, also implying a certain object size (needed for index multiplication). A nice property therefore is that the base pointer can be different each time the program is started, but the handle stays constant. So in case that module-private array is mmapped to disk, handles themselves can be serialised, unlike pointers. This can enable quick and easy storage of most of the program state, allowing for a fast recovery afterwards.
- mattgreenrocks 6y agoExcellent insight, thank you.
- vvanders 6y agoWe used to call this "seekfree" loading back in games because you could read the whole game level in one chunk without seeking on spinning media. If you wanted pointers out of it after you loaded it you just had a fix-up phase that swapped the offsets for pointers. We also used the non pointer mmap version on eMMC platforms for really easy ways to store large data while letting the kernel handle the paging with clean pages. Also forces you to think about data locality which is a powerful thing.