Currently, if an SDL2 test in Eelium test.eel aborts with an exception, it will leave a stray window, unless it has an internal cleanup exception handler. The problem here is that we essentially drop SDL2 objects in limbo, with no EEL objects to reference them, and since SDL2 supports multiple windows (unlike SDL 1.2), there's really no way we can clean up the mess at that point.
Apart from ugly hacks (exception handling and cleanup in each test), there are basically two ways we can go about this:
- Consider SDL2 Windows and other objects "global" from EEL's point of view, and provide an introspection API that will allow us to retrieve them in cases like these. (In this particular case, test.eel would just find and close any stray windows after a test finishes or aborts.)
- Fully enforce EEL object lifetimes in the SDL2 wrapper, so that windows, renderers, textures etc, are automatically destroyed along with their wrapper EEL objects. (test.eel would not have to do anything in this case, as everything behaves like ordinary EEL code.)
Of course, 2) is the "correct" approach, whereas 1) brutally violates the EEL memory management model, and... it might just be as simple as that. What it comes down to is mostly whether or not it can be implemented properly, without substantial performance impact, and/or requiring a modified SDL2.
Currently, if an SDL2 test in Eelium test.eel aborts with an exception, it will leave a stray window, unless it has an internal cleanup exception handler. The problem here is that we essentially drop SDL2 objects in limbo, with no EEL objects to reference them, and since SDL2 supports multiple windows (unlike SDL 1.2), there's really no way we can clean up the mess at that point.
Apart from ugly hacks (exception handling and cleanup in each test), there are basically two ways we can go about this:
Of course, 2) is the "correct" approach, whereas 1) brutally violates the EEL memory management model, and... it might just be as simple as that. What it comes down to is mostly whether or not it can be implemented properly, without substantial performance impact, and/or requiring a modified SDL2.