[Proj] Releasing 4.8.0 ?

[Frank Warmerdam]

On Sun, Aug 7, 2011 at 6:28 AM,  <support.mn at elisanet.fi> wrote:
> Hello,
>
> Before thread safe measures in library could somebody check
> and test the performance of all versions since we do not want
> to have any back steps in speed. (And maybe put a switch to
> remove such measures if they are not required if they really do
> add some overhead?)

Janne,

Doing some timetests between versions does seem worthwhile.  If
this is a major concern for you, I would encourage you to do so.  Perhaps
compare 4.6.0, 4.7.0 and trunk.

I will note that while I am concerned about performance, my
goal with PROJ.4 isn't necessarily to be the fastest projections
library.  I don't accept that any peformance regression is unacceptable.

You can configure --without-mutex on unix-like systems to
disable use of locking where it is currently found (access to
datum shift grids, and the "init file" cache).

> My suggestion would be that if somebody needs thread safety
> he adds some locking mechanism above Proj.4 so that the threads
> do not mess up (write) the data and reading only by many threads
> is not a problem? What exactly are the changes made in Proj.4
> from 4.6 to 4.7?

Your suggested approach was used in the past, but it was an
unnecessary limitation in most cases so it was decided (by me
at least) that PROJ.4 should become multi-thread safe.

This has been accomplished by two main means.

1) Implement an exclusion lock around access to some
shared resources, in particular the datum shift grids and
the cache of initiations loaded from init files (like 'epsg').

2) Implement an execution context object, visible at the
application layer, that can be used to segregate different
threads.  The most important thing put in this thread was
the "pj_errno", but some other things, like error handlers
as well.  This allows us to implement reentrancy without
mutual exclusion locks.

There was also a bit of cleanup of other unnecessary static
data I think.   Some of this work, the exclusion locks in
particular, was already done in 4.7.0.  The context work is
in 4.8.0 and requires using slightly different function entry
points to get full advantage.

The introduction of a context should likely have been
vetted by an RFC process.  I am still willing to do so
if there are several members of the community who would
like us to have a chance to consider whether or not to go
this direction.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer