On Wednesday 16 April 2014 14:46:56 Branislav Katreniak wrote: > > As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk > > measured the difference between the current approach and using atomics > > using Olivier's initial benchmark, it's about 4-5x slower for checking if > > there's a callback set. Since this is affecting every Qt application on a > > not uncommon hot path, I'd rather trade in theoretical tool stability for > > general performance. > > The register / unregister methods can do the actual work in the > QApplication thread to avoid locking.
That's too simple-minded. The problem is that not just register/unregister (cf. QInternal:: {registerCallback,unregisterCallback}) would need to be thread-safe, but also the code path where the callback is triggered (cf. QInternal::activateCallbacks). Remember, assignments to pointer-sized variables are not atomic on all platforms, hence QInternal::activateCallbacks could be triggered while some callback function pointer is still garbage. And we cannot just call that one in the main thread as that is a hot path (esp. for addObject/removeObject events). > To support more callbacks, the pointer can be pointer to linked list > of function pointer + context instead of pure function pointer. Yep. That's what QInternal already does. Greets. -- Kevin Funk _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development