Is the DataSource.delete() method (from java binding) thread safe? Thanks
On Wed, Jan 11, 2012 at 3:09 PM, Even Rouault <even.roua...@mines-paris.org>wrote: > ** > > Le mercredi 11 janvier 2012 22:32:45, Billy Newman a écrit : > > > I am using a third party lib (imageio-ext) to leverage gdal in java code. > > > I have noticed that the imageio-ext folks have wrapped the gdal.Open(..) > > > call in a synchronized method. I am assuming this is to prevent > > > imageio-ext users from hanging themselves with regard to thread safety. > > > > > > I have looked at the gdal FAQ with regards to thread safety and the last > > > release that it mentions additions is 1.3.0. > > > > > > What is the current status of the 1.9.* build with regards to thread > > > safety. > > The following is still true : "In particular for the situation where many > threads are reading from GDAL datasets at once should work as long as no > two threads access the same > GDALDataset<http://www.gdal.org/classGDALDataset.html>object at the same > time. However, in this scenario, no threads can be > writing to GDAL while others are reading or chaos may ensue. " > > I believe most common GDAL drivers should be safe. That includes drivers > that don't depend on third party librairies (the driver is self contained > in GDAL source tree), and drivers that depend on "classic" third-party > libraries (such as PNG, JPEG, GIF). For other third party libraries > (netCDF, HDF4, HDF5, ...), this depends on whether they are thread-safe > themselves. There's at least one driver that is known to be non thread-safe > : GRIB. > > > > > > Thanks, > > > Billy > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
