Brutkey

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange Yeah, you can do it that way but it's too error prone to have begin_undo since if you allow unlogged updates to happen it will desync any existing undo/redo log entries. So it's better to always log changes. Keep in mind this isn't for all memory in the system. Just for the backing memory of the arena (or whatever) you're using for that data structure you want to be semi-persistent.

mistymntncop
@blackeggs@infosec.exchange

@pervognsen@mastodon.social ahh ok, so there would just be a undo_snapshot function that creates like a bookmark since the last boundary point.

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange Correct. And remember what I said about the flexibility this opens up? You have to log the updates incrementally as they happen, but because you're not required to preserve the granularity except at bookmarks you can do things like coalesce or dedup changes since the last snapshot into an entirely different representation when someone takes a snapshot, if you'd like.

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange As a silly example, suppose there's a snapshot where all the logged changes were writes to the same byte location. The only thing you ultimately have to care about for the snapshot is the initial value of the overwritten byte from the last snapshot, so everything else can be tossed. It's more or less log compaction but you don't have to use the same representation for the most recent op log and the snapshot log, if that makes sense.

mistymntncop
@blackeggs@infosec.exchange

@pervognsen@mastodon.social that does makes sense and helps clarify things :)