-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
added GDALCacheFlushHelperHandler #4852
Conversation
By default, when a dataset being processed needs to allocate a new cache block and the global cache is already full, it is not allowed to flush the cache of other datasets to make room in the global cache, in order to prevent problems in multithreading scenarios. This callback asks the user whether it is safe to flush some dataset or not, in order to give a chance to do so and free some cache blocks. By doing so, the pressure on the cache might be released and avoid I/O congestion. It is up to the user to ensure that by answering "yes" in a multithreading scenario, flushing another dataset will not induce unexpected results. This callback cannot be installed on different thread local storages, since its purpose is to get a global answer regarding the user's known current thread states
As far as I'm concerned, I don't think this is appropriate for upstream inclusion as discussed in #4762. This is a workaround, hard to use safely and that will cludge the API |
I am ok with your position. |
I'm closing the PR indeed |
By default, when a dataset being processed needs to allocate a new cache block
and the global cache is already full, it is not allowed to flush the cache of
other datasets to make room in the global cache, in order to prevent problems
in multithreading scenarios.
The proposed callback of this PR asks the user whether it is safe to
flush some dataset or not, in order to give a chance to do so and free some
cache blocks. By doing so, the pressure on the cache might be released and avoid
I/O congestion. It is up to the user to ensure that by answering "yes" in a
multithreading scenario, flushing another dataset will not induce unexpected results.
This callback cannot be installed on different thread local storages, since its
purpose is to get a global answer regarding the user's known current thread states