If they have the ability to pause the entire game in a consistent state while its state is being saved (in the foreground save case), then they certainly have the ability to pause the entire game in a consistent state so they can fork. Just the latter pause will be much much shorter.
Ah, I see. I was assuming that the achievement of consistent state must somehow be achieved in the child.
If the parent can achieve consistent state (e.g. doing the equivalent of pressing "pause"), why not do the following instead:
While paused, memcpy the current memory to a buffer, then simultaneously {resume game, spawn thread to write the buffer to disk}. In C++ the memcpy might be even more convenient with the copy constructor.
This will introduce a short delay for the copy, at the speed of RAM bandwidth.
But that copy will need to be done anyway, straight away, as the parent poster says:
> that [copy] overhead will likely be spent in the first frame
With fork() it just happens in the kernel instead of in userspace, thus likely slower (1000s of individual sequential page faults, instead of a single contiguous allocation).
So if the fork() approach can somehow do it faster, I'd be curious via what mechanics.
A stopped thread may be in the middle of mutating an array or struct.