[Development] qt_add/removeObject hooks

[Volker Krause]

On Monday 07 April 2014 10:18:40 Thiago Macieira wrote:
> Em seg 07 abr 2014, às 17:48:46, Volker Krause escreveu:
> > The current situation is that the hooks work fine on Linux/QNX in
> > combination  with LD_PRELOAD (unless you have a non-recent gold that
> > ignores
> > QtCore.dynlist). They also work on Mac/Windows, with the nasty function
> > re-
> > writing code we have in GammaRay, but only if the compiler optimizer isn't
> > interfering (ie. actually emits those functions, and calls them,
> > preferably
> > with arguments). My attempts to keep the optimizer far enough away (MSVC:
> > __declspec(noinline), #pragma optimize("g", off), Clang:
> > __attribute__(noinline), 'asm("")' in the body) improved things but not to
> > the  point to being usable in release builds (MSVC merges both functions
> > with qt_startup_hook, and neither MSVC nor Clang provide the QObject*
> > argument).
> > 
> > So unless there's some compiler magic I missed I think this needs a
> > different  approach to be reliable and cross-platform, such as callbacks.
> > Would this be acceptable? If so, would a minimal approach similar to
> > qt_register_signal_spy_callbacks() or rather something using
> > QInternal::registerCallback() be preferred?
> 
> We should probably move those functions to a separate .cpp, so the optimiser
> doesn't kick in. We don't build with LTCG enabled.

I tried to avoid tricks that more or less worked by accident, in order to have 
something that would survive the next compiler update. With explicit compiler 
flags to disable optimization for the separate files this might work though.

> But feel free to make the best API that works for GammaRay and for Squish.
> You're the only users of such an API. We'll abide by the solutions you come
> up with.

API-wise we are quite flexible (can't get any more dirty than what we do now 
;) ), I was mainly asking due to this being on a performance-relevant path. 
The QInternal callback system is obviously more flexible (and thus would be my 
preferred choice), but also slightly more expensive at runtime. The signal spy 
approach would be slightly more light-weight, at the cost of thread-safety. 
So, if from the performance point of view there are no objections to the 
QInternal callback approach, I'll make sure the Squish team is happy with that 
too, and propose a patch accordingly.

Should this include the removal of the old add/removeObject hooks or are they 
considered public API (they are exported)?

regards,
Volker
-- 
Volker Krause | volker.krause at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4840 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140408/63030fd6/attachment.bin>