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

Missing releases and related #120

Open
lpisha opened this issue Sep 14, 2021 · 3 comments
Open

Missing releases and related #120

lpisha opened this issue Sep 14, 2021 · 3 comments

Comments

@lpisha
Copy link
Contributor

lpisha commented Sep 14, 2021

Here is a summary of all the types in OWL, and their create / release / destroy functions.

Type Create Release Destroy
OWLContext owlContextCreate N/A owlContextDestroy
OWLBuffer owlDeviceBufferCreate, owlHostPinnedBufferCreate, owlManagedMemoryBufferCreate, owlGraphicsBufferCreate owlBufferRelease owlBufferDestroy
OWLTexture owlTexture2DCreate *1 owlTexture2DDestroy
OWLGeom owlGeomCreate owlGeomRelease N/A
OWLGeomType owlGeomTypeCreate Missing N/A
OWLVariable *2 owlVariableRelease N/A
OWLModule owlModuleCreate owlModuleRelease N/A
OWLGroup owlUserGeomGroupCreate, owlTrianglesGeomGroupCreate, owlInstanceGroupCreate owlGroupRelease N/A
OWLRayGen owlRayGenCreate owlRayGenRelease N/A
OWLMissProg owlMissProgCreate Missing N/A
OWLParams, OWLLaunchParams, OWLGlobals owlParamsCreate Missing N/A

owlGeomTypeRelease, owlMissProgRelease, and owlParamsRelease are missing.

*1: OWLBuffer has both a release and a destroy, but OWLTexture which is conceptually similar only has a destroy. This seems inconsistent?

*2: Probably created internally and returned through owlGeomGetVariable, owlRayGenGetVariable, owlMissProgGetVariable, and owlParamsGetVariable.

@ingowald
Copy link
Contributor

re 2: Yes; variables never explicitly created, they get created by their 'parent' object when you call owlXysVariableGet; that said, a more consistent naming wold probably be owlXyzVariableCreateReference, because its actually a reference to a variable, and it actually does get 'created'. In that case I'd argue that'd cause more confusion than what it's worth, though, since most users would always go through owlXyzSet<..>(...), anyway.

Everything else: yes, fully agreed, should all be added for consistency.

@ingowald
Copy link
Contributor

PS: just for completeness' sake: even objects that did not get properly released by the application code will get released/destroyed when the context itself gets destroyed, so the "memory leak" problm isn't just as big as the "can't even release them" may imply.

@lpisha
Copy link
Contributor Author

lpisha commented Sep 20, 2021

I understand destroying the context releases them, however:

  1. It should be possible to do any OWL operation in a loop indefinitely, and if there's no destroy/release then the loop would have to include creating and destroying the context.
  2. OWL prints warnings about leaked objects on shutdown, including the types which are missing releases.

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

2 participants