On Thursday 05 November 2015 11:44:33 Thiago Macieira wrote:
> 3) Never unload any plugins, possibly also compiling our own libraries and
> plugins with -z nodelete. Solves most of the problems, including the C++
> vtable case.
Patch for QPluginLoader and QFactoryLoader:
https://codereview.qt-p
On Thursday 12 November 2015 09:58:15 Thiago Macieira wrote:
> Ok, thanks. I'll disable plugin unloading in QFactoryLoader in 5.6. We can
> look into merging it with QPluginLoader later.
Actually, I've just seen the difference.
~QPluginLoader:
if (d)
d->release();
~QFactoryLoaderPri
On Thursday 12 November 2015 11:54:14 Knoll Lars wrote:
> On 12/11/15 12:28, "Development on behalf of Paul Olav Tvete" wrote:
> >On Friday 6. November 2015 10.10.52 Thiago Macieira wrote:
> >> But before I go and modify QFactoryLoader... what is that class for? Can
> >> anyone find out from the o
On 12/11/15 12:28, "Development on behalf of Paul Olav Tvete"
wrote:
>On Friday 6. November 2015 10.10.52 Thiago Macieira wrote:
>> But before I go and modify QFactoryLoader... what is that class for? Can
>> anyone find out from the old history? It traces its existence back to "Long
>> live Q
On Friday 6. November 2015 10.10.52 Thiago Macieira wrote:
> But before I go and modify QFactoryLoader... what is that class for? Can
> anyone find out from the old history? It traces its existence back to "Long
> live Qt 4.5".
Added by Matthias in commit 89df363e4a795d67342d04e478af592618e16363 a
On Friday 06 November 2015 09:47:51 Koehne Kai wrote:
> The easiest way to achieve this is to ban QStringLiteral and
> QByteArrayLiteral inside Qt's own code. Somehow I doubt that this would
> have noticeable impact anyway, at least if the replacement tries to cache
> strings once constructed, inst
On Friday 06 November 2015 16:45:33 Knoll Lars wrote:
> To me this points strongly to opt for never unloading plugins. We can of
> course offer a way to force the unloading if the user does it's own stuff
> and knows what he's doing. But Qt should probably never unload any plugins
> it loads, as we
On Friday 06 November 2015 08:52:29 Welbourne Edward wrote:
> > SEP?
>
> Sorry, reference to hitch-hiker's guide to the galaxy:
> Someone Else's Problem.
https://en.wikipedia.org/wiki/SEP_field
"... is a psychological effect where people choose to dissociate themselves
from an issue that may be
> On 06 Nov 2015, at 17:45, Knoll Lars wrote:
>
> On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo"
> wrote:
Hi,
> To me this points strongly to opt for never unloading plugins. We can of
> course offer a way to force the unloading if the user does it's own stuff and
> knows
On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo"
wrote:
>On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler wrote:
>> They just need to deep-copy the
>> strings they return in the plugin interface with:
>> QString(orig.constData(), orig.size())
>> if they can be QStringLiterals and a
On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler wrote:
> They just need to deep-copy the
> strings they return in the plugin interface with:
> QString(orig.constData(), orig.size())
> if they can be QStringLiterals and are susceptible of outliving the plugin.
Given the problem is a specific case of
Thiago Macieira wrote:
> 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.
>
> Problems: libraries loaded by plugins, fragile.
+1. Caveat emptor.
Deep copying destroys the point of QSt
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> [...]
> 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 th
> SEP?
Sorry, reference to hitch-hiker's guide to the galaxy:
Someone Else's Problem.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: Thursday, 5 November 2015 5:45 PM
> To: development@qt-project.org
> Subject: [Development] RFD: plugins vs QStringLiterals
>
[snip]
>
>
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 dest
riday, November 6, 2015 00:44
> To: development@qt-project.org
> Subject: [Development] RFD: plugins vs QStringLiterals
>
>
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be an
>
On Thu, 5 Nov 2015, Thiago Macieira wrote:
It gets worse if you have KF5-based image format plugins, since kimg_eps.so
links to QtPrintSupport. Fortunately, none of them today link to other KF5
libraries, but can we continue to count on that?
Well, the KRA and OpenRaster image format plugins t
On Thursday 05 November 2015 15:50:17 Thiago Macieira wrote:
> On Thursday 05 November 2015 18:23:37 Robin Burchell wrote:
> > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > > Problem: performance impact, complexity of the atom/quark solution.
> > >
> > > to lessen the performan
On Thursday 05 November 2015 21:06:20 Marc Mutz wrote:
> On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote:
> > Proposal: force QStringLiteral uses to always address a heap-allocated
> > QString, instead of pointing to the static data. Possibly, this should be
> > an interned atom/quark
On Thursday 05 November 2015 18:23:37 Robin Burchell wrote:
> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > Problem: performance impact, complexity of the atom/quark solution.
> >
> > to lessen the performance impact, we could have a #define to control the
> > construction beha
On Thursday 05 November 2015 18:13:36 Oswald Buddenhagen wrote:
> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but
> > not
> > really unload.
>
> you already did that quite a while ago. was it reverted? or
On Thursday 05 November 2015 18:23:49 Milian Wolff wrote:
> When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the
> cost of these operations easily dwarfs the string heap allocation. So this
> is not that bad, imo.
Making a nothrow operation throwing is bad. Avoiding heap al
On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote:
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be
> an interned atom/quark à la GQuark, so two passes on the same
> QStringLiteral would
On Thu, Nov 05, 2015 at 06:23:37PM +0100, Robin Burchell wrote:
> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > > Problem: performance impact, complexity of the atom/quark solution.
> > >
> > to lessen the performance impact, we could have a #define to control the
> > constructio
On Donnerstag, 5. November 2015 18:13:36 CET Oswald Buddenhagen wrote:
> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but
> > not
> > really unload.
>
> you already did that quite a while ago. was it revert
On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote:
> > Problem: performance impact, complexity of the atom/quark solution.
> >
> to lessen the performance impact, we could have a #define to control the
> construction behavior of QSL at compile time. i'm not quite sure whether
> to make th
On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote:
> Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not
> really unload.
>
you already did that quite a while ago. was it reverted? or never
integrated?
> I've said in the past that unloading plugins is a bad
On Thursday, November 05, 2015 11:44:33 AM Thiago Macieira wrote:
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be an
> interned atom/quark à la GQuark, so two passes on the same QStringLiteral
> wou
And moc data is affected in a similar way. I continue to be in favor of (3)
Simon
Original Message
From: Thiago Macieira
Sent: Friday, November 6, 2015 00:44
To: development@qt-project.org
Subject: [Development] RFD: plugins vs QStringLiterals
Proposal: force QStringLiteral uses to always
Proposal: force QStringLiteral uses to always address a heap-allocated
QString, instead of pointing to the static data. Possibly, this should be an
interned atom/quark à la GQuark, so two passes on the same QStringLiteral
would result in the same heap pointers.
Alternative: force QPluginLoader
31 matches
Mail list logo
