Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Driver Management #18

Closed
yeesian opened this issue Mar 17, 2016 · 6 comments
Closed

Driver Management #18

yeesian opened this issue Mar 17, 2016 · 6 comments

Comments

@yeesian
Copy link
Member

yeesian commented Mar 17, 2016

https://sgillies.net/2014/01/22/rethinking-driver-management-in-fiona-and-rasterio.html

Maybe we should not register all the drivers when importing the module, since we do not call GDALDestroyDriverManager()?

@visr
Copy link
Member

visr commented Mar 20, 2016

Sean writes about problems with Python's atexit module.
Do we also have these problems? Could we for instance add a finalizer to the module itself? I tried some things, but not sure how to test if it is working.

julia> module A
       f(A) = println("cleaning up...")
       finalizer(A, f)
       end
A

julia> module A; end
WARNING: replacing module A
A

julia> gc()
cleaning up...error in running finalizer: ErrorException("task switch not allowed from inside gc finalizer")
finalizer(GDAL, GDAL.destroydrivermanager)
finalizer(GDAL, GDAL.destroy)

@yeesian
Copy link
Member Author

yeesian commented Mar 20, 2016

Could we for instance add a finalizer to the module itself?

I don't think we can: JuliaLang/julia#8764.

The deeper issue is that it isn't clean for driver registration to be a side-effect of importing the module; and it won't be possible for downstream packages to reverse that.

@visr
Copy link
Member

visr commented Mar 20, 2016

Ah thanks for the link. Ok I agree on the side-effect not being very clean. Shall we just remove the driver register functions from the __init__, or also provide a context manager function in this package?

@yeesian
Copy link
Member Author

yeesian commented Mar 21, 2016

I think removing the driver registration functions from __init__ should be fine. There still isn't a particularly clean solution to (automatically) decide which functions to provide do-block equivalents for. Some relevant reading: https://lists.osgeo.org/pipermail/gdal-dev/2010-September/026027.html

@meggart
Copy link
Member

meggart commented Mar 21, 2016

I am trying to catch up a bit with your progress, so sorry for stupid questions. Would this mean that the driver registration and destruction would have to be handled by the user? How would a downstream package handle this?

@yeesian
Copy link
Member Author

yeesian commented Mar 21, 2016

Yup,

This would mean that driver registration and destruction will have to be handled by downstream packages/users, e.g.

import GDAL
GDAL.allregister()
...
GDAL.destroydrivermanager()

A downstream package might provide a do-block context e.g.

module FriendlierGDAL
import GDAL
function registerdrivers(f::Function)
   GDAL.allregister()
   try
      f()
   finally
      GDAL.destroydrivermanager()
   end
end
end

Such that users can do something like

import FriendlierGDAL
FriendlierGDAL.registerdrivers() do
   ...
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants