-
Notifications
You must be signed in to change notification settings - Fork 596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
invalidate() on a cached entry doesn't seem to reset its m_configspec? #1632
Comments
btw ImageCacheFile::m_configspec is a memory leak (allocated in the constructor, never deleted) |
since m_configspec is set in the ImageCacheFile constructor, the only clean way to do it would be that invalidate() actually deletes the ImageCacheFile, but it merely seems to keep it in an invalid state, so that the next add_file() does nothing. |
I think you are basically correct about all this. There are performance and safety reasons why we don't want to delete the whole ImageCacheFile upon invalidation. But, I think that the real problem is that add_file, if the file already exists, just does nothing (and in particular does nothing with the config passed to it). I think a better behavior is that add_file of a file that already exists in the cache ought to invalidate it and use the passed configuration as a replacement for whatever config it may have had before. I'll see if I can prepare a patch to address this, and also the leak that you point out. |
I think add_file should do nothing if the file already exists in the cache and is valid, but should load the new config if the file was invalidated. If add_file always invalidates the file, then we need a way in the API to know if a file is present and valid in the cache, because we don't want to invalidate the cache every time we load a file (I do add_file every time I open a file, because I have no way to know if it is already in the cache and valid) |
OK, that makes sense to me: add_file should not invalidate, but if the file it mentions is already invalidated, it can replace the config with the new one. Working on it. |
I think that this old issue was addressed by the fairly recent PR #2021. That change (which can be found in OIIO 2.0 as well as master) added a So I'm going to close this. Please re-file if the new feature is inadequate. |
Here's my use case, but I'm not sure if I'm doing something wrong, or OIIO does:
Am I doing something wrong?
Is there a way to reopen a file with a new config spec?
The text was updated successfully, but these errors were encountered: