RFC5 Thread safety incomplete, even to phase 1 standards?

[ravenAtSafe]

Phase 1 of RFC5 (Thread Safety) appears to be complete according to SVN (although main RFC page says the entire thing is done).

http://trac.osgeo.org/csmap/wiki/CsMapRfc5

http://trac.osgeo.org/csmap/wiki/CsMapRfcs

I note however, that CS-MAP uses global variables, all marked as csThread.

e.g. error reporting uses these guys from CSData.c:

csThread int cs_Error = 0;
csThread int cs_Errno = 0;
csThread int csErrlng = 0;
csThread int csErrlat = 0;
csThread unsigned short cs_ErrSup = 0;

That looks promising until you go to cs_map.h and see that csThread is defined to be nothing, and therefore all those thread variables are really global variables. This is my read on it, at least. Have done no testing.

Unclear if all the other csThread tagged variables are problematic, but error logging sure looks thread unsafe.

[Norm Olsen]

While Phase Two has not as yet been completed, Phase One works as intended, although there may yet remain a defect or two. Operations involving the dictionaries are defintely not thread safe. Many geodetic transformations are not thread safe. The operations which are considered thread safe are most all projections and geodetic transformations of the geocentric type (i.e. transofrmations which do not access grid files). These operations are thread safe in that by design, they are not supposed to generate any errors; they simply return status.

The idea is that once completely setup, a full conversion could indeed be thread safe provided it does not use a grid interpolation datrum transformation method. Conversion and transformation methods are supposed to work without reporting errors through CS_erpt regardless of the numeric values they are asked to convert.

Accessing a grid file is obviously subject to errors such as I/O errors. Without a locking mechanism, two threads seekeing around in the same file (same file descriptor) is definitaly no thread safe. So, grid file interpolation transformation methods are marked as being non-reentrant (i.e. NOT thread safe).

The csThread modifier was deprecated some time ago and was intended only to be effective in a DLL environment. I don't think that it ever worked as expected.