[Interest] Event inspection after delivery
kshegunov at gmail.com
Sun Jul 22 23:25:37 CEST 2018
On Sun, Jul 22, 2018 at 7:08 PM, Sérgio Martins <iamsergio at gmail.com> wrote:
> For statistics you probably want to use tracepoints .
On Sun, Jul 22, 2018 at 8:13 PM, Giuseppe D'Angelo via Interest <
interest at qt-project.org> wrote:
> And in particular this patch:
> https://codereview.q <https://codereview.qt-project.org/#/c/229165/>
*ETW may refer to: East to West, an American Contemporary Christian music
> duo active 1993–1997; Eastern Trombone Workshop, one of the largest annual
Thanks, but please correct me if I'm wrong though. Isn't the purpose of
this to profile and/or trace around the code for optimization purposes?
Can I get realtime information while my program's running and can I get
this in release mode through an API of sorts?
I'm trying to balance out worker objects in a thread pool, so I'd need to
process this in-code.
On Sun, Jul 22, 2018 at 7:05 PM, Thiago Macieira <thiago.macieira at intel.com>
> > Yes, I read the warning, that's why I posted here. My follow up
> > would then be:
> > How will the fine grained control that notify() gives be replaced, or
> > it be at all?
> Unknown. That needs to be developed.
> The problem in question is that notify() is a virtual function in
> QCoreApplication, which means we can't thread-safely deliver events in
> auxiliary threads while the main thread is either constructing or
> the QCoreApplication. My inkling is to simply ignore the QCoreApplication
> outside the main thread. Hence the warning.
> > And is considering event post-processing (akin to the event filter which
> > goes before the QObject::event) sensible?
> It hasn't been necessary for the last 25 years.
> > I realize mine is somewhat of an edge case, but I'd be surprised if no
> > had needed that before ...
Okay, fair enough.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest