Logger thread safety when JUCEApplicationBase::moreThanOneInstanceAllowed() always returns true

General JUCE discussion
1

I was making an application and willing to pass FileLogger object to Logger::setCurrentLogger(). Then suddenly, a warning popped into my head. “Thread safety?”.
Let me ask if what I describe below is correct or not…

When JUCEApplicationBase::moreThanOneInstainceAllowed() returns always true, I should pass a logger class(Inherited from juce::Logger) that has static CriticalSection object (and that will lock in Logger::logMessage()) as a member variable even if I don’t call Logger::writeToLog() except in main thread, because juce::Logger has static Logger pointer object, that will be shared in all application instances, which means more than a thread will access to the object, and that means it needs static lock.

If so, I should make custom logger class instead of FileLogger class, because FileLogger class has non-static CriticalSection.

2

All problem has solved by having a static FileLogger object in somewhere in my app!
I tested code below to create two or more instances(although it’s really rough!!) .
No concurrency occured as far as I can tell.

Can I ask one more question?
Is it really OK that Logger class has non-atomic Logger pointer?
I think it should be std::atomic<Logger*> because it will cause concurrency when an instance call Logger::writeToLog() and another instance call Logger::setCurrentLogger() at the same time.

3

Are you talking about an app, not a plugin? If so, they will have different static instances.

4

Oh, really? I didn’t know that!
Yes, as you mentioned, I have experienced horrible bug when I developed a plugin which has static member attributes…That’s why I misunderstood!