[geos-devel] Thread safety issues

[Even Rouault]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20170629/bebb2369/attachment.html>