Pierre Chatelier

I understand that sharing the limbs from both interfaces is not really possible, but it would be great to have a standard API call to adapt the limbs from one...

Would it be possible that when deciding to evict a block from the global cache, if first *tries* to lock it (with a timeout 0) whatever the dataset it belongs...

> my conclusion of all my past attempts to fix this is that it won't work. [...] I believe that for write scenarios only a per-dataset (or per-thread) block cache...

I would try a pull request, but I quite not fully understand the code GDALRasterBlock::Internalize(). I am pretty sure that there is a minor modification to allow the cache flush...

I would like to try my proposal just above of `std::unique_ptr GDALAbstractBandBlockCache::makeDatasetPurgeable(GDALDataset* d)` (or something like that) to locally let the user responsible of "there is no multi R/W concurrency"

I understand your point of view. That's why instead of adding a method to GDALDataset, I thought it was more relevant to add a method to the cache manager, because...

Ok, so you think that adding such a method is doomed and would just become obsolete after a cache redesign, leading to backwards API compatibility problems. That makes sense. So...

Since I am really concerned by this cache limitation, I did not give up. I have a new proposal that you might judge acceptable. What about an installable global callback...

> This is were open source shines: you can experiment that in your own fork pending that a hopefully cleaner solution emerges some day... I will with this proposal, because...

Just in case #4852 (will certainly be refused for now)