[Proj] libproj4 thread safety

Patrick Mézard 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
> following:
> 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
> employed.
> Any subsequent call to pj_init will immediately reset pj_errno prior to
> processing
> 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
> cause
> reset of any error flags associated with the argument projection
> structure
> 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
> pj_errno.

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
question :-).

> 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.

Patrick Mézard

More information about the Proj mailing list