Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't lock the device state when preparing a new effect state
There is technically a small race condition with the device getting reset on a separate thread at the same time, but the way the locks get ordered would otherwise risk a deadlock (alAuxiliaryEffectSloti first locks the context's mPropLock and mEffectSlotLock before initEffect locks the device's StateLock, while alcCreateContext and alcResetDeviceSOFT first locks the device's StateLock before UpdateDeviceParams locks the context's mPropLock and mEffectSlotLock). In contrast, the race condition may (depending on timing) set up the effect state with an older or mixed device format and assign invalid or null pointers, which will get properly reset and cleaned up after the device is reconfigured and before restarting.
- Loading branch information