Control flow - nosefish/FishySigns GitHub Wiki

• server classloader - server's classloader loads the FishySign class
  • watchers is empty
  • instance.get() is null
• plugin.enable() called
  • instance set to this - static weakref to the plugin instance. Might need to be made atomic
  • Log is initialized - Log class is not really needed anymore, can use FishySigns
  • ChunkTracker is started
  • ServerTicker is initialized - ServerTicker looks superfluous, but isn't, because it's thread-safe and Canary's stuff isn't. Calling Canary's getServerTickCount or whatever it's called outside the main thread may return a stale value.
  • FishyTaskManager is initialized - depends on ServerTicker
  • Watchers are enabled - there are probably none, because their classes haven't been loaded.
  • FishySignClassLoader loads all fishy sign classes from fishysigns directory
  • Find all FishySigns in all currently loaded worlds and chunks.
  • PluginListeners (watchers usually are PluginListeners, too) are enabled. - are there any Watchers at this point? (Answer: Maybe. They are loaded when they are first referenced; in this case when a FishySign registers with them. That may have happened in the previous step if the plugin was reloaded or loaded when the server was already running) What happens when you register them twice? (answer: nothing at all, the second attempt will be ignored.)
• Control is passed to the PluginListeners

FishySigns are only active in chunks that are completely surrounded by loaded chunks. This prevents glitches with signs on chunk borders.

• When the ChunkTracker notices that a chunk meets the criteria for sign loading, it starts a FishySignFinderTask for that chunk.
• The FishySignFinderTask searches the chunk's TileEntityList for signs.
• For each sign, it creates a thread-safe UnloadedSign instance. When the whole TileEntityList has been processed, it creates a FishySignLoaderTask and passes it the list of UnloadedSigns.

• The FishySignLoaderTask runs outside the server thread. For each sign, it simply calls FishySign's static loadAndRegister method.
• loadandRegister calls the FishyClassLoader's makeFishySign method
• makeFishySign goes through the list of FishySignIdentifiers and tests if the pattern matches. When a match is found, it assumes that the associated class is the right one to use for this sign. TODO: would caching location-class improve performance? The FishySign subclass is instantiated with the UnloadedSign passed to the constructor and the instance returned to loadAndRegister.
• The FishySign's validateOnLoad method is called. If it returns true, the sign is assumed to be valid. Otherwise, the reference to the uninitialized FishySign is dropped, leaving the object for garbage collection.
• The valid FishySign is anchored to the ActivationManager with a BlockAnchor. When the sign's chunk is unloaded or the sign is destroyed later, the BlockAnchor will remove its reference to it and the FishySign becomes garbage.
• the FishySign's startInitTask method is called, which submits a FishyTask to call the initialize method and execute the code defined by the subclass TODO: does this extra task make sense?