Since chunks are sent to the FileIOThread for async saving, could we make the whole process async?
Or rather, a method with a callback that would be ran async to simply add all the current chunks to the async saver.
I am able to successfully save a world by calling a normal save() async, although sometimes I get a generic "stopTiming called async" throwable.
Not sure if it's safe? But it does indeed put chunks into the saver if all you're concerned about is a quick save before unloading and archiving.
(This would save 50-80ms on the main thread per forced save!)
In addition, a callback for when the world is completely saved (region files have been written to fully) would be extremely useful for anyone looking to quickly archive a world via zipping/copying immediately after saving without the risk of missing chunks.
This is an example of what may happen if you try to zip up a world immediately after a manual save() - waiting around 100-500ms after seems to be enough to completely save all the data, but It's never a good idea to wait an arbitrary amount of time in case something does take an unusual amount of time
I spent a few hours seeing how the world saving system worked, was thinking perhaps creating a list of pending chunks for that save then removing them as they are written in RegionFileCache.e()
If the async idea is just not really possible, would the callback work at least?
Though I think right now it's a bit beyond me and wanted to see if this is plausible before I spent a few more hours just to end up completely breaking it!
(Basically, async the chunk iterator in ChunkProviderServer.a():294, then call the callback when all chunks have been physically written to disk in RegionFileCache.e())
Since chunks are sent to the FileIOThread for async saving, could we make the whole process async?
Or rather, a method with a callback that would be ran async to simply add all the current chunks to the async saver.
I am able to successfully save a world by calling a normal save() async, although sometimes I get a generic "stopTiming called async" throwable.
Not sure if it's safe? But it does indeed put chunks into the saver if all you're concerned about is a quick save before unloading and archiving.
(This would save 50-80ms on the main thread per forced save!)
In addition, a callback for when the world is completely saved (region files have been written to fully) would be extremely useful for anyone looking to quickly archive a world via zipping/copying immediately after saving without the risk of missing chunks.
This is an example of what may happen if you try to zip up a world immediately after a manual save() - waiting around 100-500ms after seems to be enough to completely save all the data, but It's never a good idea to wait an arbitrary amount of time in case something does take an unusual amount of time
I spent a few hours seeing how the world saving system worked, was thinking perhaps creating a list of pending chunks for that save then removing them as they are written in RegionFileCache.e()
If the async idea is just not really possible, would the callback work at least?
Though I think right now it's a bit beyond me and wanted to see if this is plausible before I spent a few more hours just to end up completely breaking it!
(Basically, async the chunk iterator in ChunkProviderServer.a():294, then call the callback when all chunks have been physically written to disk in RegionFileCache.e())