[Bug 252126] New: akonadi blocks gui thread responsible for painting screen on login

John Stanley jpsinthemix at verizon.net
Thu Sep 23 12:16:59 BST 2010


https://bugs.kde.org/show_bug.cgi?id=252126

           Summary: akonadi blocks gui thread responsible for painting
                    screen on login
           Product: Akonadi
           Version: 1.4.0
          Platform: Compiled Sources
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: kdepim-bugs at kde.org
        ReportedBy: jpsinthemix at verizon.net


Version:           1.4.0 (using KDE 4.5.1) 
OS:                Linux

I've tried both QMYSQL and QSQLITE, and they both share the following problem:

On the first KDE bootup I have desktop effects active, the splash screen gently
fades into the desktop background, and with either QMYSQL or QSQLITE things
look ok (akonadi is running, tables are generated, etc.). Now, wait a minute or
so and log out, and then, log back in.  Now what happens is that as the splash
screen begins to fade, the screen goes briefly very dark sometimes, other times
not so dark (for 1/2- 1 sec), and then the desktop wallpaper appears
immediately after. If I log out, and then back in, same thing -- on every
re-login. If I then logout (to kdm), switch to vt1, remove the
akonadi-generated databases, switch back to vt8, login, then all is perfect
just like the very first login. Logging out, and then back in, same problem
occurs.

This is definitely not a video/driver problem. In particular, if I disable
akonadi: the problem never occurs. 

Looking at the akonadi code, I see that a number of methods us
QProcess::waitForStarted(), QProcess::waitForFinished(), and
QIODevice::waitForBytesWritten(), and/or QIODevice::waitForReadyRead(). My
understanding is that these are blocking functions which should not be used in
a GUI context. My theory is that somehow they are blocking the thread which is
doing the screen painting following login. To test this I simply inserted a
delay in server/src/storage/dbinitializer.cpp:

 83 bool DbInitializer::run()
 84 {
 85   sleep(4);
 86   qDebug() << "DbInitializer::run()";
 87 

Now, this is not a proposed fix or anything (rather silly actually), but I
wanted see if I delayed akaonadi doing the db checking/updating, it would help.
Sure enough, the issue is gone -- get a nice smooth login everytime. Now doing
this, probably will cause problems on logout. The reason why it doesn't ever
happen on the very first login, I assume is due to an effective delay internal
to akonadi: it has to generate the databases, and then only after that do any
checking/updating. For all logins after the first, it can jump right in to
doing the db table checking/updating, resulting in the blocking. Just
speculating here of course. 

Anyway, Can this be looked into ? Is there a way of doing the above
QProcess/QIODevice functions in separate thread ?

thanks much for your time,
John

Reproducible: Always

Steps to Reproduce:
see above 

Actual Results:  
see above

Expected Results:  
a gradual fade in of the desktop background

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Kdepim-bugs mailing list