Alright, I'm back to working on my proposed refactoring for LoggerContext initialization and I've come across an issue. What I wanted to do was extract a method object from the bodies of the start() and stop() methods. However, calling out to foreign code like that in a synchronized context is a great way to cause concurrency bugs.
Basically, what I'd like to know is if it's necessary to add the shutdown hook thread during a configLock. This doesn't really seem to require locking the configuration since a configuration change won't have an effect on said shutdown thread. In a related issue, why is setConfiguration locking on this instead of configLock? Or really any of the synchronized methods in LoggerContext. And with the status state switching logic, in start(), the reconfigure() call is done before status switches to STARTED. However, in start(Configuration), the call to setConfiguration() happens _after_ it's in the STARTED state (and outside the configLock section). What I'd like to propose here is that we separate out the shutdown hook logic into an unsynchronized context as it doesn't really require synchronization. I also think we should take a closer look at the use of locking in LoggerContext. With the configLock object, do we really need to use synchronized methods? -- Matt Sicker <[email protected]>
