[Proj] libproj4 thread safety
pmezard at gmail.com
Wed Feb 23 16:04:18 EST 2005
On Wed, 23 Feb 2005 13:14:26 -0500, Gerald Evenden
<gerald.evenden at verizon.net> wrote:
> Before these emails get tooo long and complicated, let me suggest the
> pj_init return a pointer if an error free initialization of a
> projections occurs otherwise
> a null value when an error occurs and the pj_errno global may be
> checked for
> the reason for failure. THIS IS THE ONLY place pj_errno will be
> Any subsequent call to pj_init will immediately reset pj_errno prior to
> the request.
> The return structure may be modified by pj_fwd or pj_inv but pj_errno
> will not
> be affected by any calls to these routines.
> Errors in the calls to pj_fwd and pj_inv will be indicated by HUGE
> values in
> both elements of the return structure. Each call to pj_fwd/pj_inv will
> reset of any error flags associated with the argument projection
> a the beginning of processing the request.
> A call to int pj_error(void *pj) will return the error status of the
> structure pj
> which reflects the last pj_fwd/pj_inv call with THAT pj structure. A
> negative number indicates an
> error occurred. To get description follow current procedures with
You no longer store the errno within pj_errno ? To check a single
return code is much better than two. However, I do not even know if
you can fold errno as a positive int value. The best thing is probably
to translate errno to internal pj_errno values. But that was not the
> The error code status in the pj structure is the only thing that is
> likely to change.
> I do not consider pj as const inside the library.
So, pj is the execution context for the library. I thought about that
before I noticed there were other public functions in lib_proj.h which
could fail and did not take a pj in input. I do not know whether it
would make your proposal harder to implement or not, you tell us...
Actually this is the best way to go, IMHO.
More information about the Proj