Le mardi 07 février 2012 00:23:20, Billy Newman a écrit : > Is the DataSource.delete() method (from java binding) thread safe?
Yes, it should > > 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
