Skip to content
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

Closed
wants to merge 10 commits into from

Conversation

chacha21
Copy link
Contributor

@chacha21 chacha21 commented Nov 18, 2021

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

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
@rouault
Copy link
Member

rouault commented Jan 20, 2022

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

@chacha21
Copy link
Contributor Author

I am ok with your position.
I am really using that feature, though, that's why I am keeping the branch in touch with origin/master
Do you want me to delete the pull request so that it won't raise more notifications ?

@rouault
Copy link
Member

rouault commented Jan 20, 2022

I'm closing the PR indeed

@rouault rouault closed this Jan 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants