[Proj] libproj4 thread safety

Glynn Clements glynn at gclements.plus.com
Sat Apr 23 22:13:11 EDT 2005

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.:

	#define pj_errno (*pj_errno_loc())
	extern int pj_static_errno;
	#define pj_errno pj_static_errno

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>

More information about the Proj mailing list