Mutex locking was introduced around pj_transform to protect against the possibility of crashes a long time ago: http://comments.gmane.org/gmane.comp.gis.mapnik.devel/462
We now avoid this locking if proj 4.8 (current unreleased trunk) is detected, but I think we should do the same for 4.7.
My hunch is that the original problems were likely encountered due to pj_init (which proj 4.7 now protects against) and not pj_transform as I am unable to prompt crashes in unprotected pj_transform with proj 4.7 within TileMill, which uses multithreaded rendering.
This move is valuable because proj development is stalled and so linux systems relying on packages are stuck at 4.7 leading to cases for mapnik where multithreaded rendering is extremely slow.
avoid mutex locks on pj_transform for proj 4.7 and above - closes #1072
add proj 4.7 mutex change to changelog - refs #1072
remove #1072 from changelog as it was ultimately reverted from 2.0.x …
Revert "add proj 4.7 mutex change to changelog - refs #1072"
This reverts commit 6824b87.
found a case, only replicable on linux, where this is not going to fly and causes cascading proj_init errors. So, reverted.
Thank you, you save my day! Just met a lot of random proj_init errors (and broken tiles) after using datasources with different projections in TileMill. After updating work like a charm =)
Revert "avoid mutex locks on pj_transform for proj 4.7 and above - cl…
This reverts commit 150c9f8.
This reverts commit 0748d2b.