SafePointer or similar for Processor?

I have a case where my Processor object needs to tell the editor to repaint(), but since this can happen from a thread that is not safe to call repaint() on, I need a method similar to using Component::SafePointer in order safely use the this object’s editor pointer in a lambda for the MessageManager::callAsynch() method. This kind of protection works fine from any of my view classes, but since the Processor is not a Component, it won’t compile there. How can I safely call repaint() on a pointer to my editor object from my processor class?

Short answer: you can’t.
The editor could be destroyed the very moment, when you want to call your repaint() or any other method.
Stopping the editor from being destroyed would be only possible involving a message manager lock, which is a priority inversion (making your high priority audio thread wait for the low priority message thread to give the lock up).

EDIT: however, using the message manager queue is an option, but posting that callAsync is considered potentially problematic (it allocates a message)

MessageManager::callAsync() compiles just fine when used from AudioProcessor code. What exactly is the error you are getting from the compiler? It does however have some runtime caveats that make it not the best option to use. (Namely, your GUI thread objects might be deleted before the async call happens.)

The problem I’m trying to solve is one where I sometimes get a crash when the conditions tell my code to inform the editor that it needs to repaint. I think I’ll avoid this situation entirely, and just set a flag in my processor that the editor can test for in its timer callback. Since this only happens when the editor actually exists, there will never be a conflict.

1 Like

OK, but a crash is not a compile time problem… :wink:

Right, but my attempted solution to the crash caused a compile time problem, which was that my Processor could not use the methods that I’ve used in my components to allow repainting safely when they responded to parameter changes. A flag works much cleaner in this case, since the timer callback of my editor will never be called in the process thread.

Why can’t you just change an atomic flag from the audio thread that the GUI thread polls via a timer to see if it should repaint?

Edit: responded before reading the whole thread.

It’s be super nice if there was a thread-safe lock-free repaint call built into Component :slight_smile: . This is a fairly common problem :slight_smile:

1 Like