[Proj] libproj4 thread safety

Gerald Evenden 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 
admit that
this can be confusing when more that one projection pointer is active 
and it
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 
in the
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 
just a
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
> location]
> Hello,
> 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 */
> pj_errno;
> //-------------
> 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 :
> <http://article.gmane.org/gmane.comp.gis.proj-4.devel/831>
> ---
> "-- 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 
> get
> 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
> 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

More information about the Proj mailing list