[Proj] Releasing 4.8.0 ?

[support.mn at elisanet.fi]

Frank,

if you are only using local variables in stack.. there are no thread
problems since each thread has it's own variables.. the point is
just to remove all globals and instead of referencing globals
calling access functions to protected locals. Basically each
thread should have it's own variables in stack or where ever.

I have not tested the speed of 4.7 but I had the feeling after switching
back to 4.6 that all proj.4 operations had an increase of speed and
that is why I am suspicious about the 4.7 coding? Especially the
startup initialization of projections was much faster in 4.6.

Since I do not need thread safety even if my projects mostly are
multi threaded (only one thread handles the projections) I would
not like to have any drawbacks in speed. So that I really prefer a
switch that would remove all unnecessary thread related overhead.

Frank, can you run "Diff" for 4.6 and 4.7 (or 4.8)? I don't have the tool
installed right now here.

http://en.wikipedia.org/wiki/Diff
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html

Regards: Janne.

--------------------------------

Frank Warmerdam [warmerdam at pobox.com] kirjoitti: 
> 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
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>