[Proj] libproj4 thread safety

[Gerald Evenden]

Let me ask the question: given a program that is executing libproj4 
library
members only active at only one point in the program?  That are there 
are no
parallel processes accessing the same memory other than in the context
of shared libraries?  When a process has called an entry point to 
libproj4, then
any use of global variables would be OK as long as their state was 
returned
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 
libproj4
but except for the condition at the return of pj_init its value is 
meaningless
at the return of any other entry.  Secondly, no other entry to libproj4 
library
can be made to libproj4 library entry while another entry is being 
processed.

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 
hyperspace.
;-)

  In addition, the error status of any projection pointer is preserved 
regardless
of how many executions are made with other projection pointers.

If paragraph 2 is allowed then current internal actions regarding 
pj_errno can
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 
upon entry
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 
not acceptable
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

Another example:
  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 
the same
process then all bets are off.  That is, libproj4 rouitines can only 
processing
one structure at a time handling pj_errno

It all boils down to what one means by "simultaneous.".  I understand 
how
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
>> 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
> _______________________________________________
> 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