[Development] RFD: plugins vs QStringLiterals

[Welbourne Edward]

IIUC, the problem Thiago is discussing is a crash on exit(), or after
main() has returned.  This limits the scope of the problem (we don't
make applications crashy while running), but only somewhat.  There may
be things in the application loading a plugin that rely on clean
shutdown, including destructors of the application's globals, which may
get skipped if a (long ago unloaded) plugin's globals cause a crash
before the application's destructors get their turn.

Thiago asked:
>> What do we do then?
>>
>> 1) Declare it SEP and only apply workarounds for the places where
>> QStringLiteral is used in our plugins, suggesting that people do the same in
>> their plugins.

On 05 November 2015 18:02, Sergio Martins <sergio.martins at kdab.com> replied:
> +1 for SEP
> Document the circumstances where QSL might crash so the user can
> decide for himself what he values most.
>
> Customers will usually want stability, so they probably won't use QSL,
> but for many projects, like KDE, it's important to remove all those
> heap allocations and we tolerate a crash now and then. These crashes
> are very rare, and when they happen they are easy to diagnose and
> fix. Until now I've only seen the dbus crash you fixed and the QRegExp
> crash which I debugged in 15 minutes yesterday.

The problem with SEP is that it only works in so far as there *is*
something the author of client code can do about the situation.  They
may not have enough choice to control this.

Qt is a framework.
It gets used in many ways.
This makes it hard to say what options clients have - or don't have.
In the end, SEP means telling some class of potential clients of Qt that
Qt has made a design decision that means they have to use something
other than Qt.

The client code may be a plugin for an application that the plugin
authors can't influence, that unloads whether the plugin authors like it
or not.  It is not unheard of for an application to include a "plugin
blacklist" of plugins known to cause problems; if the application
developers dislike crash-on-exit, they may then blacklist the plugin.
Authors of plugins in such contexts can't sensibly use Qt, unless we can
ensure that "unloading" doesn't actually unload.  Of course, such an
application is likely using naked dlopen/dlcose, not our helpers.

The application may be long-running, loading and unloading plugins on
demand: it may end up loading new versions of a plugin it has previously
unloaded.  (There are at least two APIs for web server plugins;
fortunately, these are usually loaded in separate processes; but a lean
mean new web-server supporting those APIs to ease migration to it as
replacement might handle things differently.)  As Thiago mentioned, any
don't-really-unload solution breaks this.

We likely have to live with some element of SEP: the other solutions
only mitigate the problem or limit its scope, so we have to document the
remaining cases where Qt won't be a good choice for plugin authors.  We
should at least try to make that a problem for as few potential clients
as possible.


I played around with this problem (in my ignorance) last month.  It
seems *some* globals in plugins do get destructed when the library gets
unloaded.  This surely is what should happen.  However, others did not;
I failed to work out why (partly due to getting distracted by a red
herring).  If we can work out what causes the difference and work out
how to get globals to go away on dlclose(), we may have a better
solution.  However, I failed to see a way to do that.

	Eddy.