On Thu, Aug 21, 2014 at 8:26 AM, Even Rouault <even.roua...@spatialys.com> wrote:
> > I guess the silence in thread is due to people being impressed by the > austerity of the topic... > Something like that :) > > On the other side, I would be very pleased with having "just" the > preliminary > step of Blake's work, i.e. the possibility to choose a per-band block cache > strategy instead of the global block cache. That should already address > most > scaling issues. > I agree - from reading it seems like the major improvement is shifting away from a global, locking cache to a per-dataset cache. (ah. has been edited since you read it?) Which personally I think is worthwhile for any code/application which reads a variety of gdal datasources. Quick question - presumably for VRT datasets any source images currently share the global cache and are treated from this proposals' POV as their own "datasets"? As well as the VRT being a separate dataset? If so, seems like this could be quite a major win for users with VRTs for tiled images? While it's a lot of code change, it's mostly simple/repeated changes. > Solution 2 (RW Mutex in GDALRasterBlock) > Cons: > It means that writing a driver is not as trivial as before and care must be taken in how locking is done within the driver in order to prevent deadlocks and maintain thread safety. I'm wary about making drivers more complex, there's a lot of them. And many are unlikely to be tested in multi-threaded anger during initial development (and MT issues can be hard to unit test). Can you explain a bit further what would be the impact for typical driver styles? Can we make the typical case (no/locked multithreaded access) really easy? What sort of driver code would be needed for drivers that can do MT reads? MT reads and writes? Rob :) OT: can we change gdal-dev to be reply-all by default? :) -- *Koordinates*PO Box 1604, Shortland St, Auckland 1140, New Zealand Phone +64-9-966 0433 koordinates.com <https://koordinates.com/about>
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev