[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