[Proj] libproj4 thread safety

[Patrick Mézard]

> Ok, I think I understand.  But how can the library exist in the
> unsophisticated non-thread
> world without bothering users with this "odd" requirement.  I do not
> understand how the
> naming of these functions is handled with multiple copies.(?)

With #ifdef ... as all platform dependent stuff. That's why want to
avoid the inclusion of threading stuff into your library which is
currently platform independent, and put a pj_errno member within
pj_init pointers.

You can check libpng as an example for thread-safe library. First the
user allocates a context structure the it passes it every time he
calls a libpng function. They do not know about threading primitives,
they just isolate execution contexts.

> How are error flags handled for the math library in the threaded
> environment?  Close to the
> same issue.  I do not do much checking here as the code does so much
> manipulation
> to avoid math library problems.
> >>
> >> I think the earlier change of adding pj_error(void *pj) would also be
> >> a reasonable
> >> suggestion for all applications but the structure would become
> >> non-const.
> >
> > Seriously, I think this solution is better. The library would be
> > naturally thread-safe without getting into threading stuff and users
> > would just have to read the doc to use it properly. The question is :
> > are you sure you can replace pj_errno everywhere with a version
> > embedded in pj_init pointers ? Aren't they other functions setting
> > pj_errno and not dealing with pj_init pointers ?
> 
> Note, global pj_errno is still required in this version for internal
> operations.

The question is : could it be replaced by the pj_init pointers version
? If it only occurs in library internals, then it could be replaced
without impacting client code. In the meantime I will go with thread
local storage.

Patrick Mézard