Thanks! Educational as ever, this closes out a few hanging threads for
me, much appreciated.
Cheers, Mike
On Mon, Jun 3, 2024 at 3:48 AM Even Rouault
wrote:
> Michael,
>
> https://github.com/OSGeo/gdal/pull/10108 will fix it.
>
> You can also workaround the issue by overriding the extent
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
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
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
