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).
Not on the same dataset object, otherwise you'll get crashes as no lock
is taken
(*) 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.
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.
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.
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.
Laurentiu
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
