On jeudi 29 juin 2017 23:19:30 CEST Tamas Szekeres wrote: > Dear developers, > > We have encountered thread safety issues when invoking the geos C api from > multiple threads on a site with strong traffic. > > Specifically CLocalizer is using std::setlocale which is not thread safe. ( > http://en.cppreference.com/w/cpp/locale/setlocale). Do we have a workaround > to this?
This strongly reminds me of similar issues we have hit in GDAL and proj.4 In GDAL, we've now a CPLThreadLocaleC class that use Linux & Windows thread-locale specific API to force the C locale when available, and otherwise default to a setlocale() call protected by a mutex (which only protects 2 concurrent calls to setlocale(), but not a setlocale() with a printf()) See https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2785 https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_conv.cpp#L2843 But ultimately I ended up rewriting my CPLvsnprintf() to avoid messing up with the C locale, and just using vsnprintf() with a later replacing of the comma by decimal point (I guess this must be the use case in GEOS too ?) : https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1119 And similarly for CPLsscanf() : https://github.com/OSGeo/gdal/blob/trunk/gdal/port/cpl_string.cpp#L1430 Not sure if those are the best way of addressing the issue (I'd wish there would be API using always the C-locale), but they are now rather well proven. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel