On 17 Oct 2016, at 15:27, Thiago Macieira 
<thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote:

Em segunda-feira, 17 de outubro de 2016, às 15:50:04 PDT, Konstantin Tokarev
escreveu:
17.10.2016, 15:48, "Thiago Macieira" 
<thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>>:
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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to