This is basically the main "chunk" class for internal FAWE. Chunk operations should (and are) almost always single-threaded operations, however, under certain circumstances it is possible for the chunk to be "called" (flushed: written to the world and sent to the player) from a separate thread. This would specifically occur from SingleThreadQueueExtent when there are a lot of chunks being loaded in memory by FAWE (where the chunk would then be submitted to a multi-threaded queue). It would therefore be possible for a thread accessing the chunk to attempt to access it in the middle of the call, which can lead to a number of issues, and it is my opinion that the most frequent of these is the NPE seen during lighting operations, where new chunks can be accessed/loaded very quickly, increasing the likelihood for the aforementioned synchronisation issue to occur.
Co-authored-by: Matt <4009945+MattBDev@users.noreply.github.com>
* Update so many dependencies, merge Forge/Fabric for final
* Clean up contrib docs for Gradle change
* Fix setting compat flags while using toolchain
* Fix deprecation in doc printer
* Restore proper forge JAR name
* Add dist classifier for mod jar
* Properly relocate new bStats
* Fix jar used from fabric
* Fix fabric bom
* Dup the shaded classes for consistency
* Sync Forge/Fabric log4j versions, de-dup
* Downgrade both log4j. This will work
* Update some plugins as well
* Drop the fabric force stuff
* Use duplicate strategy to directly merge jar
- Add a "loadPrivately" method to be used when GetChunks are called to avoid synchronocity issues with super classes being used on different threads
- Synchronise the call method so we're not attempting to call whilst also loading/updating
- Properly ensures we don't try to submit chunks that already have a monitor (prevent the FAWE-freezing)
- We can't detect if "no" threads hold the chunk's monitor, but equally that would also be kinda very bad practice.