[Proj] libproj4 thread safety

[Glynn Clements]

Gerald Evenden wrote:

> The problem of the thread safe version of pj_errno for
> libproj4 seems to be taken care of with the following file:

[details snipped]

Seems fine.

> Note that some return error checks are not made but what
> to do if they fail??  Can't set pj_errno. :-(  Maybe
> should just call one of the exit procedures.

AFAICT, all of the error conditions boil down to inability to allocate
a resource. According to the documentation:

+ pthread_key_create() will fail if you exceed the maximum number of
keys (1024 on my system).

+ pthread_setspecific() can fail due to insufficient memory (or if the
key is invalid, which means that pthread_key_create() failed).

+ pthread_getspecific() and pthread_once() can't fail.

Neither seem particularly likely to occur in practice. 1024 keys is
plenty (a library which uses per-thread storage typically uses a
single key), and if memory is so short that pthread_setspecific()
can't get enough memory to store a key/value pair, the process doesn't
have much of a future.

> Next problem is how to handle this procedure for both those
> interested in threads and those not caring a whit.  If it
> is placed in libproj4.a, users have to link with '-l threads'
> regardless of using threads.  Make two different libraries?
> Do not include pj_errno.o library and force user to include
> pj_errno.o on compile line?  Note: I will include a compile
> switch to allow for compiling as either a vanilla or pthreads
> version---it makes no difference to the macro inclusion nor
> the remainder of the libproj4 system.
> 
> Comments, suggestions would be appreciated here.

One possibility is to put all of the pthread code into a separate
source file, and conditionalise the pj_errno definition, e.g.:

	#ifdef PROJ_USES_PTHREADS
	#define pj_errno (*pj_errno_loc())
	#else
	extern int pj_static_errno;
	#define pj_errno pj_static_errno
	#endif

If the user compiles without PROJ_USES_PTHREADS, pj_errno_loc() will
never be referenced, so the corresponding .o file from libproj.a won't
get linked in, so there should be no references to the pthread
functions in the final executable.

-- 
Glynn Clements <glynn at gclements.plus.com>