diff options
| author | Jesse Yurkovich <jesse.y@gmail.com> | 2021-11-13 07:47:26 +0300 |
|---|---|---|
| committer | Jesse Yurkovich <jesse.y@gmail.com> | 2021-11-13 07:47:26 +0300 |
| commit | e8a8bb67fcefa5e935214e1af1ec3da38465dda1 (patch) | |
| tree | 36778df9dd5ecfbd4bc3ba18f7418263abe803f0 | |
| parent | ab9ec193c34ae62af99350f62631f91c9648d5eb (diff) | |
Cleanup: Correct order of guard and lock in moviecache_valfree
Fix own mistake in rB7061d1e39fe
In my attempt to quickly address T92838, along with the original bug, I
made a nonsensical choice to use the limiter lock to guard the check
against the cache item itself. While harmless, it is not necessary and
semantically wrong / potentially confusing to future readers of the code.
Differential Revision: https://developer.blender.org/D13122
| -rw-r--r-- | source/blender/imbuf/intern/moviecache.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/source/blender/imbuf/intern/moviecache.c b/source/blender/imbuf/intern/moviecache.c index 1bc0a4e628d..8923ba98e08 100644 --- a/source/blender/imbuf/intern/moviecache.c +++ b/source/blender/imbuf/intern/moviecache.c @@ -122,11 +122,11 @@ static void moviecache_valfree(void *val) PRINT("%s: cache '%s' free item %p buffer %p\n", __func__, cache->name, item, item->ibuf); - BLI_mutex_lock(&limitor_lock); if (item->c_handle) { + BLI_mutex_lock(&limitor_lock); MEM_CacheLimiter_unmanage(item->c_handle); + BLI_mutex_unlock(&limitor_lock); } - BLI_mutex_unlock(&limitor_lock); if (item->ibuf) { IMB_freeImBuf(item->ibuf); |