[Development] qt_add/removeObject hooks

[Volker Krause]

On Tuesday 08 April 2014 23:53:11 André Pönitz wrote:
> On Tue, Apr 08, 2014 at 11:00:18PM +0200, Olivier Goffart wrote:
> > On Tuesday 08 April 2014 07:42:46 Thiago Macieira wrote:
> > > Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
> > > > 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.
> > > 
> > > Performance-wise, I'd prefer empty functions that get overridden at
> > > runtime. That's the smallest overhead for when they are not present.
> > 
> > According to a quick benchmark (attached), it is clearly more efficient to
> > 
> > have:
> >   if (callback) callback();
> > 
> > where callback is a function pointer than always calling callback even if
> > it is an empty function.
> > 
> > For this reason, I'd recommend an approach based on function pointer
> > callbacks such as QInternal::registerCallback
> > (but that one is using a QGlobalStatic, so there is room for improvement)

Thanks for the benchmark, my gut feeling also was that a likely to be false 
comparison would beat a function call, but I hadn't verified that yet.

> I don't think there's a need to get overly fancy with a registration
> interface for such things. This is not "common user API", but
> special-purpose access for tools that are already heavily tied to Qt core
> guts anyway, in an attempt to make their maintenance simpler while not
> disturbing normal operation.
> 
> Function pointers are fine (after your measurement preferably set to 0 by
> default and checked on call), but don't need to be accessible to any kind
> of "public" beyond what the tools need for their operations.
> 
> Speaking for debugging here, I'd be happy enough to have a reliable method
> to access some compile-time constants that are not easily accessible at
> run time. In this context, finding a global symbol is easy, some arithmetic
> is easy, but function calls are prohibitive. So putting all the needed
> compile-time constants into one global array without further fuzz is pretty
> much optimal.

Yep, we had to go through quite some effort to reliably detect the Qt version 
on all platforms, at runtime or before launching an application, so we can 
pick the right probe to inject. Good to know you also need this.

> Using an array of function pointers for QObject construction/destruction
> hooks or similar would serve to my best understanding a similar purpose for
> e.g. GammaRay (Volker, feel free to correct me), using quintptr and merging
> both arrays just saves a symbol and keeps the naughty parts in a single
> place. Arrays are also easily extensible without intoducing more symbols.

I'm fine with this approach (it's similar to the signal spy one, which works 
for us), just want to point out two possible/theoretical limitations:

- thread-safety: we might be setting the callback at a point where already 
several threads are active. For us it's less relevant that we don't miss a few 
calls from other threads there (attaching at runtime happens at an arbitrary 
point in time anyway), but that this doesn't crash the target application. We 
haven't observed issues with the signal spy callback so far, so probably only 
a theoretical issue (Marc, please don't hit me for this ;) ).

- multiple callback users: we would need to be reasonably sure nobody else but 
mutually exclusive debugging tools use those callbacks, especially not Qt. We 
kinda have this problem with the signal spy callback already, but luckily it's 
only needed by a rarely used feature in QtTestLib, so we don't clash there in 
practice. For GammaRay itself a single callback is perfectly fine, we have our 
own code to wrap that and dispatch it to multiple plug-ins anyway.

I'll look into implementing Andre's approach.

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/20140409/2e35b121/attachment.bin>