<div dir="ltr">Even,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The naming is perhaps not well choosen, but the documentation of the contract<br>

of this API should make it clear on what an implementation should do and what<br>
it should not do.<br></blockquote><div><br></div><div>Perhaps it should be reversed? IReadBlock and IReadBlock_not_thread_safe? (would obviously require lots of changes that way).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
You didn't answer my question on how many drivers can have a non-blocking<br>
IReadBlock() implementation in practice. My intutition (reinforced by skimming<br>
through <a href="https://github.com/OSGeo/gdal/pull/39/files" target="_blank">https://github.com/OSGeo/gdal/pull/39/files</a>) is just/mostly MEMDataset.<br>
So people looking at drivers would just see the classical IReadBlock()<br>
implementation and wouldn't have to think a lot about thread safety (that<br>
would be brought by the generic GDALRasterBand::IReadBlock_thread_safe()).<br>
<div class=""><br></div></blockquote><div><br></div><div>I honestly have no idea how many drivers can have a non-blocking IReadBlock with this setup. I really do not understand all the drivers well enough to give an estimate (so I would assume yours is probably most correct). I have been mostly concerned with first just making the cache threadsafe, then was thinking we could start targeting drivers individually. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> I somewhat like that idea that drivers<br>
> should consider their thread safety.<br>
<br>
</div>I somewhat like the idea they shouldn't have to bother about that ;-)<br>
especially if we can have improvements in core only that improve thread-safe<br>
usage and performance. The people wanting to gain one more extra % of<br>
performance might take the risk of doing a custom thread-safe implementation<br>
in the driver.<br></blockquote><div><br></div><div>My thought here was more along the lines of "the driver is going to write to the block cache so it should have the responsibility to lock when it needs to be locked". To me this was better in some manners then "in most case implement this method, which if I use improperly might cause deadlocks or corruptions, otherwise implement this method".</div>
<div> </div><div>Thanks,</div><div><br></div><div>Blake</div></div><br></div></div></div>