On 17 Oct 2016, at 15:27, Thiago Macieira <[email protected]<mailto:[email protected]>> wrote:
Em segunda-feira, 17 de outubro de 2016, às 15:50:04 PDT, Konstantin Tokarev escreveu: 17.10.2016, 15:48, "Thiago Macieira" <[email protected]<mailto:[email protected]>>: Em segunda-feira, 17 de outubro de 2016, às 13:32:04 PDT, Giuseppe D'Angelo escreveu: Il 14/10/2016 19:44, Thiago Macieira ha scritto: We are talking in this change about QFactoryLoader, which is a Qt API and which is ALWAYS used until program exit. I meant internal Qt API. ... doesn't this sound like a declaration that we're not able to have internal Qt APIs for Qt plugins that are good enough for having the plugins clean up after themselves, and be able to be unloaded without crashing? Correct. Sure, it's each plugin's fault -- especially the NM bearer plugin -- but I don't have time to figure out everything that's wrong with it. I'd rather apply this hammer to the problem than leave applications crashing on exit.> Anyhow, I've outlined a plan in my other email. It may make sense to add generic API for plugin to report if it can be safely dlclosed(), by default everything is unsafe Please read again the email that Peppe replied to: This is about QFactoryLoader, which is loads plugins at application starts and NEVER attempts to close them anyway. The only time we'd try to unload is at application exit, which is exactly when it doesn't matter because we're exiting anyway. I have to agree with Thiago. For QFactoryLoader, it doesn't make a lot of sense to try to unload the plugins, as we only do that on program exit. It would be great to make plugins safe to unload, but we all know that this is tricky to get right. In addition, we don't even control all the plugins we might be loading (thing about additional image formats of styles provided by others), so we have no way of knowing whether we can safely unload the plugin. So I think it's the right thing to change this in 5.6 and not unload those plugins on app exit. Cheers, Lars
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
