Hi all,
Thanks for the thoughts.
>From an algorithmic perspective, it's frustrating to have to wait to
read/write data. There are ways, up to a point, to avoid some of this with
the current interface, but it can make applications complicated and for
algorithms that can process blocks separately,
Hi,
I've written a piece of software that fetches tiles out of a single
MBTiles raster done by multiple threads. Tiles go to a common cache
which can be used by a "view" thread that assembles tiles on the
screen in a seamless map.
Each fetcher thread uses GDALOpenEx() and then RasterIO(GF_Read,,,)
Andrew,
what would be the purpose of thread-safe access: just making it
thread-safe without any particular requirement on how efficient this
would be (1), or hope for true concurrent access with ideally close to
linear scalability with the number of threads (2) ?
If (1), then we could add a
If the purpose of multithreading is performance, a mutex will ruin that
performance.
Opening different datasets solves that already.
For writing, allowing different synchronous writers is... scary.
On Mon, 3 Jun 2024, 16:12 Chris Toney via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:
> Hi Andrew
Hi Andrew,
Some related comments and links are in:
https://github.com/OSGeo/gdal/issues/9091
Chris
On Mon, Jun 3, 2024 at 7:44 AM Andrew Bell via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> I am aware that there isn't thread-safe raster access with the current
> GDAL interface for vari
Hi,
I am aware that there isn't thread-safe raster access with the current GDAL
interface for various reasons. Given the state of processors, I was
wondering if it would be valuable to take a look at providing the ability
to do Raster I/O (at least reads) in a thread-safe way. This could be done
t
