[Proj] libproj4 thread safety

[Patrick Mézard]

Paul Selormey wrote:

>Is there any need to really make the libproj4 thread safe?
>I think any program that is well-written should be able to
>handle the thread safety without having to build any thread
>issues into the library.
>  
>
You can always put a big lock around the thread-unsafe sections. But 
global locking is inefficient and since threads are usually about 
scalability and efficiency...

>Are these solutions being provided here applicable to 
>other platforms beside Linux?
>  
>
No, that's the problem. Solutions provided here are applicable to 
systems supporting Posix-threads APIs. Win32 systems do not (there are 
ports, like pthread-win32 but again non-native threading layers are less 
efficient than native ones and the port is designed for portability not 
efficiency). I do not know what would be the correct solution for Win32. 
_declspec decorators can be used with MSVC 7.1 to make variables belong 
to thread-local-storage but I do not know how generic this solution is.

Root of the problem is the library has not been designed from start to 
be thread-safe or at least thread-neutral (that's just a statement, not 
a critic, I do understand what it was done this way - or rather why it 
was not done the other way). Thread-neutral libraries (think libpng, 
libjpg, freetype...) make the client code to initialize a context object 
storing the library state before the library functions can be used. 
Clients allocate one context per thread then every thread is isolated 
from the others. To do that with libproj, every function should be 
changed to accept a context argument and it cannot be done or it would 
break all existing code. Therefore, the library has to be aware of 
threading models/APIs of the platforms it is meant to support, which 
will be a real maintenance burden.

Patrick Mézard