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:
>> >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.
>> 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
request unload explicitly.
* It's risky when plugin uses any non-trivial piece of software, leaving alone
Qt-specific issues, so it's a responsibility of user to ensure that plugin is
it's deinitialization correctly on all target platforms, and only allow true
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.
Development mailing list