13.10.2016, 19:39, "André Pönitz" <apoen...@t-online.de>: > On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote: >> On 2016-10-12 20:59, Thiago Macieira wrote: >> >Hello >> > >> >We've got a number of issues that got fixed in 5.7 by the change that made >> >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer >> >plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new >> >issues have cropped up. I've managed to fix some, but reports from Ubuntu >> >developers indicate the latest fix only uncovered the next issue. >> >> Hi, >> >> More importantly, this also solves all the QStringLiteral related crashes >> we've been seeing. > > These would be fixable by going back to QLatin1String. > >> We need this in 5.6, but it's too big a behaviour change for an LTS release. >> We need at least a variable to turn it on/off. >> >> Suggestion which me and peppe discussed: >> >> Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a >> behaviour change in 5.6.4. >> Make it opt-out in 5.6.4 (bringing it on-par with 5.8). >> >> This gives the user a pre-warning of 3 months, it can still be turned off >> and fixes many crashes. > > I still consider the approach of not unloading plugins fundamentally > wrong. It only deepens the trench between Qt and valid approaches > at software architectures.
I think not unloading plugins is fundamentally right thing to do, if user does not request unload explicitly. Rationale: * It's risky when plugin uses any non-trivial piece of software, leaving alone any Qt-specific issues, so it's a responsibility of user to ensure that plugin is doing it's deinitialization correctly on all target platforms, and only allow true unloading if this is the case. * It's not supported on all platforms (e.g., uclibc and musl implement dlclose() as a stub). * At application exit OS will unload plugins and clean up related resources much faster than it could be implemented with unload in destructors. -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
