3 ms·

The article is more a "see that crazy thing you can" do then a "thats a good idea". It also introduces some neat little known tech. Even if "serializing" stat

The article is more a "see that crazy thing you can" do then a "thats a good idea". It also introduces some neat little known tech. Even if "serializing" state for carrying it over with a controlled restart the File Descriptor Store might still be an interesting case use (in some cases, in others it might a problem). Also you probably would dump bincode or similar for such a "carry over state" serialization, there is very little reason to go with strings. Through there are some major differences: - PRO: This approach works with types which do not implement any serialization mechanism or e.g. cyclic data structure. At least theoretically you could carry in-progress futures over a restart with that (practically it's a horror story to try to do so which likely won't work most times). - CON: This approach has issues with types containing any form of pointers, references and similar. They all also need to use the special Allocator and then there are issues if after the restart the mem file isn't mapped to the exact same address range. This makes it way harder to use, bugs can be subtle introduced and lead errors you normally can't have in rust without unsafe code. - PRO: You don't have to move/copy anything around, so if you e.g. have some huge splatted (i.e. flat in memory) structures this can safe quite a bit on upstart time. (idk. lets say some 1GiB bit mask for some kind of caching) - CON: Debugging the carried over state, or e.g. copying it between systems is not possible or at least much more complex. Reboots might also be an issue (I have to check). In generally for many use-cases this is pointles, and for the times where it's not pointless it's often either brittle or too limited and in turn better avoided. Through for a very few use-cases it can be a huge boon.

dathinab 3y ago
PS: - PRO (& CON): You don't need to take an explicit action to "save" the state, you do the action once when setting it up at the begin of the program, it's also a CON as depending on usage in case of a hard stop you can end up with a state with partial writes to it (can't happen if only used on clean shutdown) PPS: - Using mmap with MAP_FIXED to get a fixed address every execution to make pointers work _is a potential security vulnerability_ (it should have been called MAP_REPLACE IMHO). On some platforms you can use MAP_FIXED_NOREPLACE to safely do so, but I have no idea how to choose an address as there is always a risk of address layout randomization getting in your way. - on platforms where MAP_PRIVATE is implemented using a copy-on-write mechanic you could have a pattern where on a start without a fd you create the fd and load some huge data into it and then restart, when started with fd you mmap it with MAP_PRIVATE allowing you to change the data but also to always go back to the clean state by restarting. No idea for what use-case that makes sense but I found it interesting (also haven't tried it out).
- senderista 3y ago
  > I have no idea how to choose an address as there is always a risk of address layout randomization getting in your way. Where are you using mmap(MAP_FIXED) without first calling mmap(PROT_NONE) to get the base address?

dathinab 3y ago

PS: - PRO (& CON): You don't need to take an explicit action to "save" the state, you do the action once when setting it up at the begin of the program, it's also a CON as depending on usage in case of a hard stop you can end up with a state with partial writes to it (can't happen if only used on clean shutdown) PPS: - Using mmap with MAP_FIXED to get a fixed address every execution to make pointers work _is a potential security vulnerability_ (it should have been called MAP_REPLACE IMHO). On some platforms you can use MAP_FIXED_NOREPLACE to safely do so, but I have no idea how to choose an address as there is always a risk of address layout randomization getting in your way. - on platforms where MAP_PRIVATE is implemented using a copy-on-write mechanic you could have a pattern where on a start without a fd you create the fd and load some huge data into it and then restart, when started with fd you mmap it with MAP_PRIVATE allowing you to change the data but also to always go back to the clean state by restarting. No idea for what use-case that makes sense but I found it interesting (also haven't tried it out).

senderista 3y ago
> I have no idea how to choose an address as there is always a risk of address layout randomization getting in your way. Where are you using mmap(MAP_FIXED) without first calling mmap(PROT_NONE) to get the base address?