D29266: Windows: Handle QLocalSocket behavior gracefully

Kevin Funk noreply at phabricator.kde.org
Tue Apr 28 20:14:42 BST 2020


kfunk created this revision.
Herald added a project: KDE PIM.
Herald added a subscriber: kde-pim.
kfunk requested review of this revision.

REVISION SUMMARY
  On Windows the underlying implementation of QLocalSocket behaves
  differently, it seems to trigger the QLocalSocket::readyRead() signal
  then anticipated. Prior to this patch this was not handled gracefully.
  
  BEFORE:
  Let's have a look at what happens on Windows inside Akonadi's Conneciton
  class:
  
  - Akonadi data sends Hello cmd => 91 bytes
  - Akonadi resource receives data
  - QLocalSocket::readyReady() signal fires
  - Triggers Connection::handleIncomingData via signal-slot connection
  - On Windows, QLocalSocket::bytesAvailable() is just 8 bytes
  - Only the first 8 bytes are read, into the `qint64 tag` variable
  - Protocol::deserialize(...) is called
    - Internally calls waitForData(...) (=> waitForReadyRead()) a few times
  - QLocalSocket::readyRead() signal fires again
  - Connection::handleIncomingData re-entered => BUG
  
  Problematic end result:
  
    [10972] org.kde.pim.akonadicore: tag: -1099511627647
    [10972] org.kde.pim.akonadicore: Invalid command, the world is going to end!
    [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::ClosingState
    [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::UnconnectedState
  
  
  
  > Resource attempts reconnection to server, just to fail again
  ==============================================================
  
  afterwards.
  
  AFTER:
  The fix is to temporarily disconnect from the readyRead() signal while
  attempting to wait for data to deserialize commands. This in order to never
  re-enter Connection::handleIncomingData() while doing so.

REPOSITORY
  R165 Akonadi

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29266

AFFECTED FILES
  src/core/connection.cpp

To: kfunk
Cc: kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200428/4e449510/attachment.html>


More information about the kde-pim mailing list