Em ter 22 abr 2014, às 21:02:24, Milian Wolff escreveu:
> BTW: Did you really compile this with Qt5? The operator T*() is gone from
> QAtomicPointer, no?
> https://qt-project.org/doc/qt-5/qatomicpointer-members.html
It's back.
https://qt.gitorious.org/qt/qtbase/commit/19c70982517e76d89bb3da931e13
On Thursday 17 April 2014 18:11:03 Kevin Funk wrote:
> On Wednesday 16 April 2014 12:55:38 Matthew Woehlke wrote:
> > On 2014-04-16 03:18, Volker Krause wrote:
> > > On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
> > >> In other words: use QBasicAtomicPointer.
> > >
> > > As mentioned on
On Wednesday 16 April 2014 12:55:38 Matthew Woehlke wrote:
> On 2014-04-16 03:18, Volker Krause wrote:
> > On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
> >> In other words: use QBasicAtomicPointer.
> >
> > As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
> > m
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
> >
On 2014-04-16 03:18, Volker Krause wrote:
> On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
>> In other words: use QBasicAtomicPointer.
>
> As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
> measured the difference between the current approach and using atomics us
> 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
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
> Em ter 15 abr 2014, às 09:49:53, Matthew Woehlke escreveu:
> > If you add the rule that callbacks can't be removed once registered, you
> > could do an atomic exchange of the old callback for the new, and require
> > that any attached callb
Em ter 15 abr 2014, às 09:49:53, Matthew Woehlke escreveu:
> If you add the rule that callbacks can't be removed once registered, you
> could do an atomic exchange of the old callback for the new, and require
> that any attached callback calls the previously-registered callback
> also. (This wou
On 2014-04-09 03:24, Volker Krause wrote:
> - 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 anyw
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
Em ter 08 abr 2014, às 23:00:18, Olivier Goffart escreveu:
> > 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
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
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 call
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 pr
volker.kra...@kdab.com:
> > > 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 r
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 als
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
Hi,
I'm looking into making the qt_add/removeObject(QObject*) hooks useful on
more platforms. Having those available considerably improves the results you
get in GammaRay, compared to the fallback mode that tries to find objects via
global event filters and hierarchies.
The current situation i
18 matches
Mail list logo
