[Qt-interest] QFileIconProvider "leaks" DLL's (qgifd4.dll, qicod4.dll, QtSvgd4.dll, etc.)

[Niels Dekker - no return address]

Thiago Macieira wrote:
> The problem, like I explained before, is that those are plugins and 
> they
> are loaded to complement Qt functionality. Loading plugins is 
> expensive,
> so they are kept loaded forever.

Loading plugins for the first time may be expensive, but I wonder if 
re-loading those plugins a second time is still expensive. For example 
on Microsoft Windows, a second call to LoadLibrary for the same DLL is 
much faster than the first one.  Even if you have unloaded the DLL, 
between the LoadLibrary calls.  Because the OS typically still has the 
DLL is cache.

Note also that both Windows and Linux use a reference-counting mechanism 
to keep a dynamic library loaded as long as at least one component still 
has the library in use. Both FreeLibrary (Windows) and dlclose 
(Linux/Unix) just decrement the reference count of the specified 
library, and only unload when the count is zero.

I would find it disappointing if Qt would leak resources of our users, 
just to do some other users a very minor favor.  Especially because 
there does not seem to be a workaround for us.

> Qt image plugins aren't expected to change, so we
> never unload them either.

Does QFileSystemModel need to have those plugins?  Do we need to have 
them installed at the machine of our users, in order to properly use 
QFileSystemModel within our application?

At the moment, our application appears unstable, when it's using 
QFileSystemModel on a machine that does not have the plugins.  Is that a 
known issue?


Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center