<div dir="ltr">Even,<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
</div>This might be a problem in practice since the amount of cache might grow<br>
quickly. By default a VRT will open simultaneously up to<br>
GDAL_MAX_DATASET_POOL_SIZE (whose default is 100, but can be changed at<br>
runtime with the config option) source datasets.<br>
If you do a gdal_translate of the VRT (and that it has more than 100 sources)<br>
then you will need 100 * GDAL_CACHEMAX bytes for the cache.<br>
Of course once you are aware of that you can play with both configuration<br>
options to find the best settings.<br></blockquote><div><br></div><div>This is one of the reasons I would perfer to use my solution #1 or #2 rather then just adding the per dataset cache as we originally spoke about during the original development. I think we should try to preserve the global cache in some situations but still have good performance.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just throwing an idea : how about a IReadBlock_thread_safe and IReadBlock<br>
virtual methods ? The first one would have a default implementation in<br>
GDALRasterBand that would basically call the second one with a global mutex.<br>
That way drivers that wan't a more fine grained locking could implement their<br>
own IReadBlock_thread_safe, whereas the ones that don't care would just<br>
implement IReadBlock. The few current call sites of IReadBlock would just need<br>
to be updated to call IReadBlock_thread_safe instead.</blockquote><div> </div></div>I originally thought about such a solution, but I decided instead on the using of the default IReadBlock paramter  'void ** phMutex = NULL'. If the pointer pointer of the mutex is NULL, then no mutex is created and locking does not occur. Honestly as well when I was originally doing this, I was not sure which drivers would have even needed such a IReadBlock_thread_safe implementation. Therefore, I decide the best way in Solution #2 was to simply just walk through each of the implementations of and find where exactly I need to protect the data pointer. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I have a mixed feelings on both methods. I feel like the IReadBlock_thread_safe implementation might make people writing new drivers feel like they do not have to work about thread safety when they are comparing the code to other drivers? I somewhat like that idea that drivers should consider their thread safety. Lots of drivers seem to call RasterIO as well, which would that need a RasterIO_thread_safe method? That might make that code more complex? Not quite sure, will have to think it all out.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Blake</div></div>