<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <blockquote type="cite"
      cite="mid:2be40407-bd4b-487a-a10a-154c056927b6@betaapp.fastmail.com">
      <div style="font-family:Arial;">Of course, but I'm asking if it's
        worth calling ReadBlock on multiple threads (if it always takes
        a lock, it's not, and I should use RasterIO instead).<br>
      </div>
    </blockquote>
    Not on the same dataset object, otherwise you'll get crashes as no
    lock is taken<br>
    <blockquote type="cite"
      cite="mid:2be40407-bd4b-487a-a10a-154c056927b6@betaapp.fastmail.com">
      <blockquote type="cite" id="qt" style="">
        <blockquote type="cite"
          cite="mid:87756158-76a1-4ab5-aa08-95e231973fd7@betaapp.fastmail.com">
          <div style="font-family:Arial;"><br>
          </div>
          <div style="font-family:Arial;">(*) I think these can also be
            implemented at VSI level by wrapping a file handle and
            turning Seek + Read into a PRead (when supported), even for
            drivers that don't explicitly support PRead.<br>
          </div>
        </blockquote>
        <p>The multi-threaded optimization also works for VSI file
          systems not supported PRead(), but doing what you mention
          above: doing Seek+Read under a lock. This is of course less
          efficient.<br>
        </p>
      </blockquote>
      <div style="font-family:Arial;">I meant something slightly
        different here: if a file supports PRead, but a driver doesn't
        (maybe it's using some external library like libtiff, which has
        _tiffReadProc and _tiffSeekProc), threading could still be
        supported with a hack. The driver could ask the library to open
        the same file multiple times, wrapping the same VSI handle, but
        passing in a seekProc that only keeps track of the current
        offset. So the library could seek and read as it pleases, but
        GDAL would turn those into PRead calls. The backing file handle
        would never see a seek, just PRead.<br>
      </div>
    </blockquote>
    <p>Ah I see what you mean. Having generic multi-threading isn't
      possible. Each driver would have to be modified to be ready to
      cope with that. Besides file handles, there are often other state
      variables at the GDALDataset/GDALRasterBand level.</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:2be40407-bd4b-487a-a10a-154c056927b6@betaapp.fastmail.com">
      <div style="font-family:Arial;">Laurentiu<br>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>