diff options
author | Geoff Crossland <gcrossland+bukkit@gmail.com> | 2017-08-11 17:27:33 +1000 |
---|---|---|
committer | md_5 <git@md-5.net> | 2017-08-11 17:34:19 +1000 |
commit | 963b19c5995b14f8980a42f13b1bd693a5b411d1 (patch) | |
tree | 498aed22c94a0f6a988f9300aaf7e3f46773f5c8 /nms-patches/BlockPortal.patch | |
parent | 27b8bf91169642a61f9cf888432cf018773d7df0 (diff) | |
download | craftbukkit-963b19c5995b14f8980a42f13b1bd693a5b411d1.tar craftbukkit-963b19c5995b14f8980a42f13b1bd693a5b411d1.tar.gz craftbukkit-963b19c5995b14f8980a42f13b1bd693a5b411d1.tar.lz craftbukkit-963b19c5995b14f8980a42f13b1bd693a5b411d1.tar.xz craftbukkit-963b19c5995b14f8980a42f13b1bd693a5b411d1.zip |
Fix a few chunk saving race conditions
* ChunkRegionLoader.c() picks an entry in the save queue, removes that entry from the save queue and then actually writes the entry to the region file. So, between the last two steps, the entry is neither in the save queue nor is it in the region file; if somebody loads the chunk again (with ChunkRegionLoader.loadChunk()) in that gap, they'll get old data. I've delayed the removal until the saving is done.
* ChunkRegionLoader.c() also records the coords of the chunks it's currently saving in this.c. ChunkRegionLoader.a(ChunkCoordIntPair, NBTTagCompound), which adds an entry to the save queue, stops the addition of an entry if its coords are in this.c. Now, I'm guessing that Mojang's intended purpose for this mechanism was to prevent multiple parallel writes for the same chunk. The "stops the addition" bit above should then be something like "block until it's no longer in c"; in fact, the vanilla implementation is "discard the new state of the chunk". I've taken the easy route to solving this, by just making ChunkRegionLoader.c() synchronized (since, in normal use, only the chunk saving thread is in here).
Diffstat (limited to 'nms-patches/BlockPortal.patch')
0 files changed, 0 insertions, 0 deletions