[Development] Backporting the "stop unloading plugins" change to 5.6

[Konstantin Tokarev]

13.10.2016, 19:39, "André Pönitz" <apoenitz at 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