You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GTiff supports multi-threaded reads by using PRead (and, I suspect, by doing the I/O outside of libtiff/libgeotiff). It would be useful if this could be extended to reading single blocks. Currently, the alternatives are:
not using threads
opening the file multiple times: this works, but is not really cache-efficient, and doesn't work well with the low default NOFILE limit
reading larger regions using the existing threading support: this will be less efficient when the caller knows it only needs to touch a limited number of blocks
The text was updated successfully, but these errors were encountered:
lnicola
changed the title
FR: Allow concurrent reading of single blocks
FR: GTiff: Allow concurrent reading of single blocks
Sep 21, 2023
if this could be extended to reading single blocks
I don't see any easy resolution for that. This goes against a lot of assumptions in the design of GDAL. If that was going to be implemented, it would have implications probably on core and should be done driver by driver, with a lot of caution to lock the appropriate data structures, and probably a driver capability advertising that sch multi-threaded reads can be safely done. For GTiff, not only the file access should be done in a per-thread way, but a TIFF* handle also hides a lot of state and shouldn't be used from several threads.
GTiff supports multi-threaded reads by using PRead (and, I suspect, by doing the I/O outside of libtiff/libgeotiff). It would be useful if this could be extended to reading single blocks. Currently, the alternatives are:
NOFILE
limitThe text was updated successfully, but these errors were encountered: