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 
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

Reply via email to