[Proj] libproj4 thread safety

[Gerald Evenden]

Message embedded below
On Feb 24, 2005, at 2:59 AM, Patrick Mézard wrote:

> 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.
>
Ok, I think I understand.  But how can the library exist in the 
unsophisticated non-thread
world without bothering users with this "odd" requirement.  I do not 
understand how the
naming of these functions is handled with multiple copies.(?)

How are error flags handled for the math library in the threaded 
environment?  Close to the
same issue.  I do not do much checking here as the code does so much 
manipulation
to avoid math library problems.
>>
>> 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 ?

Note, global pj_errno is still required in this version for internal 
operations.
> 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
>
>
> _______________________________________________
> Proj mailing list
> Proj at xserve.flids.com
> http://xserve.flids.com/mailman/listinfo/proj
>
>
_____________________________________
Jerry and the low riders: Daisy Mae and Joshua.
"The whole religious complexion of the modern world is due to the
absence from Jerusalem of a lunatic asylum." Havelock Ellis, 1914