Considerations and issues when using NSAutoreleasePool in Qt

There are a few issues with how we use autorelease pools in Qt:

• Our main() does not have a root autorelease pool, as it ideally should. This means any autoreleased resources in main(), e.g. during widget construction, show(), anything before app.exec(), will end up in no pool at all, and won't be released until application shutdown. This means we will have NSWindows e.g. being closed but not deallocated. Even if we had a root pool, these resources would still be released on application exit, so the better approach would be to do app construction/setup in a callback from the main runloop, where there is a pool that's drained on every spin of the runloop.
  • A consequence of this is that we need to add local pools to QCocoaWindow functions that may autorelease, since these are called during main() via show() e.g.
  • Can be debugged with OBJC_DEBUG_MISSING_POOLS=1
• When a Qt application is used as a plugin we must make sure we never autorelease any Qt objc-classes to a pool owned by the host, as when the plugin is then unloaded and the pool drained, we'll try to run code in unmapped images. It could be argued this is the host's job to manage. A workaround for us is making sure our plugin images are never unmapped. This actually happens automatically on newer macOS versions due to using thread-locals.