[Proj] libproj4 thread safety
gerald.evenden at verizon.net
Wed Feb 23 19:35:29 EST 2005
Let me ask the question: given a program that is executing libproj4
members only active at only one point in the program? That are there
parallel processes accessing the same memory other than in the context
of shared libraries? When a process has called an entry point to
any use of global variables would be OK as long as their state was
to the same condition at return as their state at entry?
What I am driving at is that pj_errno can be used during execution of
but except for the condition at the return of pj_init its value is
at the return of any other entry. Secondly, no other entry to libproj4
can be made to libproj4 library entry while another entry is being
These questions may seem dumb, especially a few years ago, but I'm never
sure that some Star Trek processor is not doing some gee whiz stuff in
In addition, the error status of any projection pointer is preserved
of how many executions are made with other projection pointers.
If paragraph 2 is allowed then current internal actions regarding
remain in place and upon pj_fwd/pj_inv return the projection pointer
will be updated
with the contents of pj_errno. IF NECESSARY, pj_errno can be saved
and restored so that the last return code of a pj_init can be
recovered. I do not
think that this is very important. If conditions in this paragraph are
then we have a lot of coding to do---or resort to long-jumps.
Lastly: fully functional examples:
A = pj_init();
B = pj_init();
assume A and B not null:
r1=pj_fwd(A,) // projection fails, contents of r1 HUGE
r2=pj_fwd(B,) // projection OK, r2 valid
pj_error(A); // returns negative error code
pj_error(B); // returns 0 --no error
r1=pj_inv(A,pj_fwd(B,r1)); // perfectly valid
If pj_fwd fails pj_error will return error code for both A and B calls;
the inverse call will fail because of HUGE input.
If pj_fwd OK but pj_inv fails only A shows error. B OK.
Note that B could be identical to A (eliminating the second pj_init but
we would lose the independence of the error checking.
If the code operates like a forked process except that we are still in
process then all bets are off. That is, libproj4 rouitines can only
one structure at a time handling pj_errno
It all boils down to what one means by "simultaneous.". I understand
multiple processes can function "simultaneously" and be syncronized by
various means but I do not see how a single process can have multiple
paths of execution --- if that is what we are talking about?
Are we getting anywhere or am I totally out in left field?
On Feb 23, 2005, at 4:04 PM, Patrick Mézard wrote:
> 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
>> 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
>> 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
> 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
> Proj mailing list
> Proj at xserve.flids.com
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
More information about the Proj