| We have stumbled into the issue of GL installed exit and signal
| handlers (especially with Quake-style load/unload of DLL's).
| Our current reasoning is that "fail safe"/"fool proof"
| mechanism of this kind only cause trouble. It is the
| applications responsibility to ensure graceful exit on error,
| and to release any GL contexts.
|
| Comments? Is this a potential candidate for ABI spec?
An app should not have to explicitly destroy its contexts
to exit cleanly, but if it doesn't then a leak detection
tool should properly report various leaks (file descriptors,
memory, associated with the context). A good OpenGL
implementation will clean up kernel and accelerator resources.
It is a bad idea for OpenGL (or any low-level client library)
to install signal handlers. They generally cause problems
for the app (e.g., segfault and bus error handlers).
atexit handlers, and handlers on thread creation and destroy
can be used, but there can still be trouble with resource
limits, e.g., say the libc implementation allowing a finite
number of atexit handlers. There is also the issue of
uninstalling at dlclose time, but I believe that there
are sufficient hooks to implement this.
My experience has been that very few apps/libraries are
written carefully enough that they can successfully unload
a dll, and there hasn't been much pressure to do better.
Is your experience different? I don't think it makes sense
to specify exit/dlclose requirements for OpenGL implementations,
but rather inherit them from some other part of the linux-base
specification, assuming that they can achieve agreement on
them. Exit/close behavior is a general philosophy for libraries,
not just OpenGL.
david
