Le Wednesday 27 May 2009 23:17:39 Karney, Charles, vous avez écrit : > Thanks for the reply. > > > At first sight, you're likely doing things the right way and probably > > discovered a bug related to multi-threading in GDAL. The use of > > GDALCreateGenImgProjTransformer() should be thread-safe (provided that > > you don't use the same dataset in the different threads) > > Yes, each thread is dealing with a separate set of files. > > > By reviewing the code of 2 files that are used in the retrieving and > > parsing of the csv files, there are a few variables that are supposed to > > be thread-local (CPL_THREADLOCAL), but this is currently a no-op. > > > > But as it's just a guess and maybe not the real cause for your problems, > > ideally, you could file a bug in the GDAL Trac with a small program that > > reproduces your issue, so that it can be investigated further. > > It's probably going to be tough for me to carve out a test case. > However, can I turn the question around? If CPL_THREADLOCAL is a noop, > how can the code in cpl_csv.cpp possibly be thread safe?
You're right. That part of the code isn't currently thread-safe, and should likely be fixed. So this is a bug, as GDAL core is intended to be thread-safe (with somes restrictions, like operating on different dataset handles, etc...). But it's hard to tell without a way of reproducing if it is significant in the issue you're running into. It might be somewhere else in GDAL. > > In the meantime, I've put a lock around by GDAL calls which avoids the > errors (but probably with penalty in performance). > > -- > Charles Karney <ckar...@sarnoff.com> > Sarnoff Corporation, Princeton, NJ 08543-5300 > > Tel: +1 609 734 2312 > Fax: +1 609 734 2662 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
