[Proj] libproj4 thread safety

Patrick Mézard pmezard at gmail.com
Thu Feb 24 02:59:24 EST 2005

Gerald Evenden wrote:

> Did a little browsing on the thread business.
> Libproj4 is not thread safe unless action is taken on pj_errno  It is 
> my understanding
> that something can be done about it but details are beyond me at the 
> moment.
> To my knowledge, all other active space is purely stack activated and 
> there are no
> other static variables.  Everything is saved in the pj_init pointer 
> which, at the moment
> and to the best of my recollection can be considered const after 
> return from pj_init.
> Does that answer the question/problem?

Completely. If the pj_errno issue is solved, the library could be 
considered thread-safe. And it would hold true even if pj_init pointers 
are not "const". They just cannot be shared by threads but there is no 
problem with that as long as it is documented somewhere.

> Secondly, I do not want to try to make the error flagging part of the 
> internal
> procedural calling.  Too long and involved procedure and would require 
> extensive
> shaking down of libproj4 to make sure it runs proper.
> It is my understanding that the problem of pj_errno can be handled by 
> threading
> procedure and I would be glad to install any conditional compile 
> statements
> to facilitate that enhancement.

This is the first solution : replace the pj_errno access with 2 accessor 
functions you declare but the client defines. Then you use these 
functions to set or get pj_errno inside the library. Client code must 
implement both function with thread local storage or anything else.

> I think the earlier change of adding pj_error(void *pj) would also be 
> a reasonable
> suggestion for all applications but the structure would become non-const.

Seriously, I think this solution is better. The library would be 
naturally thread-safe without getting into threading stuff and users 
would just have to read the doc to use it properly. The question is : 
are you sure you can replace pj_errno everywhere with a version embedded 
in pj_init pointers ? Aren't they other functions setting pj_errno and 
not dealing with pj_init pointers ?

To be honest: I probably do not care more than you about error codes 
when projection calls return HUGE. What I was afraid of was in some 
cases pj_errno would be the only way to check error conditions, that's 
all. I need robust error handling, details are optional.

Patrick Mézard

More information about the Proj mailing list