Deleted AsyncUpdater before callback

General JUCE discussion
1

Sorry for the naive question, I’m having difficulties trying to figure out what will happen if the following happens in that order:

  1. AsyncUpdater object (e.g. some ParameterAttachment) triggers async update
  2. AsyncUpdater object is deleted
  3. handleAsyncUpdate() callback invoked from the message thread

Thanks.

2

AFAIK into the AsyncUpdater destructor a flag is set to avoid to deliver the message anymore.
Hence the handleAsyncUpdate is never called.
The message is something that is reference counted.
It doesn’t dangle (still owned by the message queue) once the AsyncUpdater is deleted.

As usual, please correct me if i’m wrong (i just had a quick look into the JUCE code).

1 Like
3

That seems correct to me.

A good hint gives the jassert in AsyncUpdater destructor:

So it is safe as long as the AsyncUpdater (i.e. the object that inherits AsyncUpdater) is destroyed on the message thread, which is advisable for all things that use the message queue.

2 Likes
4

Ah, I missed the reference counted AsyncUpdaterMessage, makes sense, now.

And yes, the object which inherits AsyncUpdater would be destroyed on the message thread in my case.

For the record, I need to delete then create new ParameterAttachments on-the-fly in reaction to some other parameter changes. This’ll be managed by the editor so I guess that’s fine.

Thanks!

5

In that case the same advice like for all parameter changes applies: Make sure the callback doesn’t come from the audio thread, which can happen if you listen to the AudioProcessorParameter::Listener.

1 Like