Optional GLFW termination on library side if client code initializes it. #2687
Comments
|
Have you tried using flags? Perhaps a function parameter to one of your library methods? This seems like more of a client-issue rather than a GLFW one. |
|
I think that would pass the burden up the client stack while the core issue remains. For example, client C depends on my library L1 and also another library L2. If L2 internally initializes GLFW without notifying C, there is no way C can pass on that information to me, i.e. L1. If I then terminate GLFW thinking no one else is using it that would break L2. This information, whether GLFW is initialized has to be centralized and the best place is GLFW itself following KISS principle. I don't see any downsides to having a Thanks. |
|
That's a valid point. It would also be relatively simple to implement. I'd suggest patching the library yourself until this issue can be properly reviewed by a maintainer. For example, you could add a function signature (i.e. int glfwIsInitialized(void) {
return _glfw.initialized;
}I've not compiled, but I am 99% sure the following code would work perfectly for your purposes. |
|
I have created a pull request for the patch if it helps. |
Hi,
I have a library that uses GLFW to setup the context for OpenGL offscreen rendering. At the moment, I initialize and terminate the it around my API calls.
However, the client code could also be depending on GLFW and needs it to remain in a initialized state after completion of my API functions, i.e. my library should not terminate GLFW if the client code initialized GLFW for its own purposes.
I was thinking of checking if it was already initialized upon entry to my API and if so not terminate, but #2036 mentions this is not possible as of now, and attempts to add reference counting have been hanging for a long time #2070.
Are there any workarounds for this use case?
The text was updated successfully, but these errors were encountered: