Suspend in AAX possible race condition?

I guess, in the AAX wrapper isSuspended() should be called BEFORE the call-back lock is acquired?

So that suspendProcessing(true) will guarantee no callback will happen after calling it?

bump

I can’t see how this would turn into a race condition. Could you spell it out more clearly?

After calling suspendProcessing (true); it should be guaranteed that processBlock is NOT being executed.

This can only happen if in wrapper isSuspended() and processBlock are called under the SAME callback-lock scope.

Which seems to be guaranteed in VST, VST3 and AU but not in AAX.

There is a gap between calling isSuspended and acquiring the lock, if another thread calls setSuspended(true) while being in this gap -> processBlock will be called

 void process (const float* const* inputs, float* const* outputs, const int sideChainBufferIdx,
                      const int bufferSize, const bool bypass,
                      AAX_IMIDINode* midiNodeIn, AAX_IMIDINode* midiNodesOut,
                      float* const meterBuffers)
        {
         ...
         bool isSuspended = pluginInstance->isSuspended();
         ...             
         ...
         // lock will be acquired inside process(...) subroutine
         process (channels, numOuts, bufferSize, bypass, midiNodeIn, midiNodesOut);

solution could be just move the
const ScopedLock sl (pluginInstance->getCallbackLock());
to the first process-method, before isSuspended

OK, I see now - I thought your original post was saying that the check should be done before the callback lock is held.

That would certainly fix the race, but it’s unclear if it’ll cause any other issues. This will probably take some time to work out the neatest solution.

Ah yes, sry for confusion.

just a reminder, because this has potentially crashy behaviour, if you rely that after suspendProcessing(true) there will be no callbacks.

My temporary solution is just to to check (!isSuspended()) inside the processBlock again.

1 Like

Has this been fixed? :wink:

bump, @t0m sorry to bother you so, but the issue can result in a crash and should be fixed with high priority

this is important

fixed?

2 Likes