Changes between Version 10 and Version 11 of FAQMiscellaneous


Ignore:
Timestamp:
Jan 4, 2016, 4:06:07 AM (8 years ago)
Author:
Even Rouault
Comment:

Update regarding thread-safety and numeric locales

Legend:

Unmodified
Added
Removed
Modified

  • FAQMiscellaneous

    v10 v11  
    55== Is the GDAL library thread-safe? ==
    66
    7 No. GDAL is not completely thread safe.
     7There is not a plain yes/no answer. When care is taken, GDAL use should be thread safe in most situations ( we cannot exclude that historic/esoteric drivers might have thread safety issues ). One important point is that the same [http://www.gdal.org/classGDALDataset.html GDALDataset] object should not be accessed by several threads at the same time. But of course, it is fine to use 2 different handles pointing to the same file in 2 threads (*).
     8Before GDAL 2.0, it was not safe either to have a thread doing write operations on a dataset while one or several other threads were doing read operations on (other) datasets. Starting with GDAL 2.0, this is now possible.
    89
    9 However for GDAL 1.3.0 much work has been done on making some common scenarios thread safe. 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 [http://www.gdal.org/classGDALDataset.html GDALDataset] object at the same time. However, in this scenario, no threads can be writing to GDAL while others are reading or chaos may ensue.
    10 
    11 Also, while the GDAL core infrastructure is now thread-safe for this specific case, only a few drivers have been vetted to be thread safe.
    12 
    13 It is intended that work will continue on improving GDAL's thread safety in future versions.
     10(*) When using GDAL .vrt files, special care must be taken. See the [http://gdal.org/gdal_vrttut.html#gdal_vrttut_mt Multi-threading issues] section of the VRT tutorial.
    1411
    1512== Does GDAL work in different international numeric locales? ==
    1613
    17 No. GDAL makes extensive use of ''sprintf()'' and ''atof()'' internally to translate numeric values. If a locale is in effect that modifies formatting of numbers, altering the role of commas and periods in numbers, then PROJ.4 will not work. This problem is common in some European locales.
     14Starting with GDAL 2.0, this should work in most cases.
    1815
    19 On Unix-like platforms, this problem can be avoided by forcing the use of the default numeric locale by setting the ''LC_NUMERIC'' environment variable to ''C'', e.g.
     16In earlier versions, GDAL made extensive use of ''sprintf()'' and ''atof()'' internally to translate numeric values. If a locale is in effect that modifies formatting of numbers, altering the role of commas and periods in numbers, then PROJ.4 will not work. This problem is common in some European locales.
     17
     18On Unix-like platforms, this problem could be avoided by forcing the use of the default numeric locale by setting the ''LC_NUMERIC'' environment variable to ''C'', e.g.
    2019
    2120{{{