[Proj] libproj4 thread safety
pmezard at gmail.com
Sun Apr 24 10:29:02 EDT 2005
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.
More information about the Proj