[Proj] libproj4 thread safety
gerald.evenden at verizon.net
Wed Feb 23 10:04:41 EST 2005
I am not familiar with the concept of threads so I cannot give a
answer to the question but I will make the following comments. The
is used during the initialization call because there is not any other
way to return a reason for failure to return a viable projection
Presumable, an error condition argument could be added to the
call but a great deal of checking of internal procedures would be
to ensure that this method will work.
When an error occurs with an open projection the returned coordinates
flagged with HUGE values and, in some conditions, pj_errno is set. I
this can be confusing when more that one projection pointer is active
would seem that this condition could be alleviated with a 'errno' flag
the structure and limit pj_errno's use to initialization call.
This change looks reasonably easy by merely altering F_ERROR and I_ERROR
macros and the basic definition of struct PJconsts. There would have
to be a
review of code for other situations occuring during forward/inverse
I patterned the opening procedures after C file procedures where a
to open the file resulted in a null functional value and an error code
external errno. Admittedly, I did not follow trough with equivalents to
feof, ferror and clearerr Clearerr would not be necessary as any
call to forward/inverse would clear the error condition.
Any change in this area would be significant release change and not
trivial adding of projections of correcting old projections.
A consensus of users of libproj4 is needed on this issue.
On Feb 23, 2005, at 4:25 AM, Patrick Mézard wrote:
> [This message is mostly about libproj4. If the PROJ.4 mailing list is
> not the right place to post, please redirect me to a more suitable
> 1- I am currently reading libproj4 manual and I reached the section
> concerning error management, which basically sums up to checking the
> global variable pj_errno like C-Runtime "errno".
> In "lib_proj.h", pj_errno is declared like :
> extern int /* global error return code */
> and "pj_errno.c" just defines it as an int.
> I would like to use libproj4 in a multithreaded (win32) environment.
> What is the status of libproj4 regarding thread-safety ? I gave a
> quick look to the rest of the code and everything looks allright apart
> from the pj_errno global. On this topic, the mailing list archives are
> pretty mute, there is one reference in a JNI discussion :
> "-- GDAL and Proj both use the C runtime library extensively and the C
> runtime is not threadsafe, but java is thread safe and therefore if you
> have multiple java threads trying to use your JNI functions you will
> strange/random behaviors (including crashing) of your app. The way to
> solve this is easy, you simply mark your java functions as syncronized
> using the syncronized key word. It will be slower under multiple user
> conditions, but at least it will never crash from threading issues."
> Is it relevant to libproj4 ? As far as I know, a few broken functions
> aside (strtok), C-Runtime is mostly thread-safe on platforms I know,
> so I do not really see the point here.
> Could I assume that pj_errno is the only libproj4 part which is not
> threadsafe ? (not that I'd be glad to live with that, but it could be
> corrected). Is anybody interested in having regular -thread safe-
> return codes instead (or in plus of the global variable) ? Do you
> think it can be done with a small amount of work, while leaving the
> current interface unchanged (apart from adding return values to "void"
> functions or adding new functions with new prototypes) ?
> 2- Are the opaque structures returned by pj_init thread-safe, that is,
> are they "const" in a C++ sense ? Or should I create one per thread ?
> 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