On 11/08/2016 09:14 AM, Michael Sué wrote:
Hi,
it could be a timeout of the lock used in QSettings.
Thanks for chiming in.
I use QSettings EVERYWHERE (tightly scoped) because I am big on
putting everything back where the user left it
and this call to show() is the only place that freezes.
Also, I put print statements around the call to processEvents and
verified that it takes 5 secs, SOMETIMES.
Bill
- Michael.
-----Original Message-----
From: Interest [mailto:interest-bounces+sue=sf.mpg...@qt-project.org] On Behalf
Of william.croc...@analog.com
Sent: Tuesday, November 8, 2016 2:56 PM
To: interest@qt-project.org
Cc: Thiago Macieira <thiago.macie...@intel.com>
Subject: Re: [Interest] [PROGRESS] Long pause with 5.7
On 11/07/2016 07:22 PM, william.croc...@analog.com wrote:
This sender failed our fraud detection checks and may not be who they
appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing
I am porting my app to Qt 5.7
When I run it, it appears on the screen, but there is a long pause
(~10 secs.) before it is responsive.
I ran it with strace and there is a point where it makes 100K calls
to the poll() function, which accounts for the long pause.
I tried running it in a debugger, but the app does not exhibit the
pause in that context.
Sounds like a threading race condition and running in the debugger
changes the timing just enough.
Gave the debugger another try. On some occasions, it would take the
long pause. (The pause is more like 5 seconds.) If I interrupt it,
this is the stack trace.
Note that it is in the call to show() which precedes my call to
exec().
Bill
#0 0x0000003b0a0df113 in poll () from /lib64/libc.so.6
#1 0x0000003b0bc449f9 in ?? () from /lib64/libglib-2.0.so.0
#2 0x0000003b0bc44e4c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
#3 0x00007ffff55b2740 in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from
/nobackup/whc/qt/5.7.0-shared-debug-64Bit-RH6-NoOpenGL/qtbase/lib/libQ
t5Core.so.5
#4 0x00007ffff5565229 in
QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>, int) ()
from
/nobackup/whc/qt/5.7.0-shared-debug-64Bit-RH6-NoOpenGL/qtbase/lib/libQ
t5Core.so.5
#5 0x000000000098c60b in MyProg::show (this=0x7fffffffb8d0) at
prog.cpp:562
#6 0x0000000000986551 in MyMain (argc=@0x7fffffffc15c: 1,
argv=0x7fffffffc2f8) at prog.cpp:151
#7 0x0000000000986ad9 in main (argc=1, argv=0x7fffffffc2f8) at
yoda.cpp:221
I did not notice the call to show() was a call *MY* show().
My bad, but there is still something funny going on.
Since the beginning of time I have been searching for the way to restore window
positions and sizes when a user reenters my app. This is especially tricky
under X windows with the separate client/server, various window managers and
window decorations. Following is part of my solution.
It appears that with Qt 5.7, SOMETIMES, my call to processEvents waits for the
full 5 secs even though I do not believe there is anything to do.
That is why my app is SOMETIMES unresponsive for 5 seconds when I start it up.
void
MyApp::show() {
QSize sz; QPoint pos;
{
QSettings settings;
sz = settings.value("MainWindowWSize",QSize(1200,700)).toSize();
pos = settings.value("MainWindowPos",QPoint(180,190)).toPoint();
}
if( sz.width() > 0 && sz.height() > 0 ) {
resize(sz);
move(pos);
}
BaseClass::show();
qApp->flush();
// It appears that with Qt 5.7, SOMETIMES, this call to processEvents
waits
// for the full 5 secs though I do not believe there is anything to do.
qApp->processEvents(QEventLoop::ExcludeUserInputEvents,5000);
if( sz.width() > 0 && sz.height() > 0 ) {
resize(sz);
move(pos);
}
raise();
}
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
