Fixed minor race condition and priority inversion

Development
15

I’m still trying to find a way to reproduce this / regress this in a simple example but in the meantime I must say that it would be also wise to add this as breaking change.

A rationale of knowing (even if it’s not thread safe) if there’s a editor is for some calculations you’d like to do only when there’s UI.

In our products there’s a code that do things like spectrum analyzers / meters / etc / notify on preset changes / etc only when there’s active editor.

You wrote yourself (@ed95) :

The issue with your proposed changes is that there is now a more serious priority inversion which can occur if, for example, getActiveEditor() is called in processBlock as at the moment this is guaranteed to be fast and lock-free but with your changes this may block whilst the editor is being created.

@daniel:

…which is never safe to do, since the activeEditor can be deleted on the message thread. There is no safe way to call into the editor from processBlock, the locking doesn’t change that.

Indeed, but the lock now makes it impossible for the processor to even ‘just know’ if there’s activeEditor without risk of locking on audio thread.
I still don’t see the advantage of the lock on getActiveEditor().

Here’s an example:

    if (AudioProcessorEditor* editor = processor.getActiveEditor())
    {
        processor.editorBeingDeleted (editor);
        delete editor;
    }

this is inside the AUv3 wrapper.
so if it’s assumed to be called only by the message thread than the entire call already is on the message thread.
and both getActiveEditor and editorBeingDelete (and createActiveEditor…) has locks.
But even if we had other threads,
getActiveEditor() could return something (with lock) that will be invalid the second after.

1 Like