On Wed, Apr 28, 2021 at 9:38 AM Even Rouault
wrote:
> We could have a OSRSetAutoclosePROJDatabase() global function that would
> call proj_context_set_autoclose_database() when it creates the per-thread
> PROJ context
>
> ==> ogr/ogr_proj_p.cpp
>
> An alternative would be to enhance PROJ to have
We could have a OSRSetAutoclosePROJDatabase() global function that would
call proj_context_set_autoclose_database() when it creates the
per-thread PROJ context
==> ogr/ogr_proj_p.cpp
An alternative would be to enhance PROJ to have a mode where the SQLite3
db handle would be shared amongst
On Tue, Apr 27, 2021 at 11:44 PM Alan Snow wrote:
> By default pyproj uses the autoclose option and provides this option for
> users who want better performance and know they have a single threaded
> application:
> https://pyproj4.github.io/pyproj/stable/api/global_context.html
>
Thanks for
By default pyproj uses the autoclose option and provides this option for
users who want better performance and know they have a single threaded
application: https://pyproj4.github.io/pyproj/stable/api/global_context.html
___
gdal-dev mailing list
You are correct. Here is the related issue:
https://github.com/OSGeo/PROJ/issues/1565
The solution would be to use proj_context_set_autoclose_database. This can
reduce performance for single threaded applications, so it would probably
be good to have a way to toggle it on for multi-threaded
Hi,
I have a process with a large thread pool. The threads occasionally make a
GDAL call that in turn calls a PROJ function. From what I can tell, this
causes the opening of a PROJ context that holds a handle/descriptor to the
PROJ database. I believe that this file descriptor is held open in TLS
