[Libreoffice-commits] core.git: Branch 'distro/collabora/co-22.05' - desktop/inc desktop/source

[Luboš Luňák (via logerrit)]

 desktop/inc/lib/init.hxx    |    2 +-
 desktop/source/lib/init.cxx |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

New commits:
commit 6373b1cc38c45e2b54649738ad89438a5b5320e3
Author:     Luboš Luňák <l.lu...@collabora.com>
AuthorDate: Wed Jun 8 15:23:22 2022 +0200
Commit:     Luboš Luňák <l.lu...@collabora.com>
CommitDate: Fri Jun 17 14:27:15 2022 +0200

    use recursive mutex for LOK queue
    
    Callbacks may be invoked while calling getLOKPayload(), which
    would try to lock the mutex again. I actually originally expected
    this possibility, as the comment and moving the data to
    temporaries in CallbackFlushHandler::enqueueUpdatedTypes()
    shows, I just didn't realize the used mutex wasn't recursive
    and so would deadlock.
    
    Change-Id: I2b5c4b6b4c1a3933a32ae4641830877e085f2b6c
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135499
    Tested-by: Jenkins
    Reviewed-by: Michael Meeks <michael.me...@collabora.com>
    (cherry picked from commit 118bafcfd1ce4a26ec9df912197ebd466d1bd497)
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135387
    Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoff...@gmail.com>
    Reviewed-by: Luboš Luňák <l.lu...@collabora.com>

diff --git a/desktop/inc/lib/init.hxx b/desktop/inc/lib/init.hxx
index 6132a7a302cc..b7f3722dff1c 100644
--- a/desktop/inc/lib/init.hxx
+++ b/desktop/inc/lib/init.hxx
@@ -220,7 +220,7 @@ namespace desktop {
         LibreOfficeKitCallback m_pCallback;
         void *m_pData;
         int m_nDisableCallbacks;
-        std::mutex m_mutex;
+        std::recursive_mutex m_mutex;
         class TimeoutIdle : public Timer
         {
         public:
diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index ac644c8b02ba..51167cf7871b 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -1460,7 +1460,7 @@ void 
CallbackFlushHandler::libreOfficeKitViewInvalidateTilesCallback(const tools
 void CallbackFlushHandler::libreOfficeKitViewUpdatedCallback(int nType)
 {
     assert(isUpdatedType( nType ));
-    std::unique_lock<std::mutex> lock(m_mutex);
+    std::unique_lock<std::recursive_mutex> lock(m_mutex);
     SAL_INFO("lok", "Updated: [" << nType << "]");
     setUpdatedType(nType, true);
 }
@@ -1468,7 +1468,7 @@ void 
CallbackFlushHandler::libreOfficeKitViewUpdatedCallback(int nType)
 void CallbackFlushHandler::libreOfficeKitViewUpdatedCallbackPerViewId(int 
nType, int nViewId, int nSourceViewId)
 {
     assert(isUpdatedTypePerViewId( nType ));
-    std::unique_lock<std::mutex> lock(m_mutex);
+    std::unique_lock<std::recursive_mutex> lock(m_mutex);
     SAL_INFO("lok", "Updated: [" << nType << "]");
     setUpdatedTypePerViewId(nType, nViewId, nSourceViewId, true);
 }
@@ -1539,7 +1539,7 @@ void CallbackFlushHandler::queue(const int type, 
CallbackData& aCallbackData)
         return;
     }
 
-    std::unique_lock<std::mutex> lock(m_mutex);
+    std::unique_lock<std::recursive_mutex> lock(m_mutex);
 
     // Update types should be received via the updated callbacks for 
performance,
     // getting them as normal callbacks is technically not wrong, but probably 
should be avoided.
@@ -2133,7 +2133,7 @@ void CallbackFlushHandler::Invoke()
         viewShell->flushPendingLOKInvalidateTiles();
     }
 
-    std::scoped_lock<std::mutex> lock(m_mutex);
+    std::unique_lock<std::recursive_mutex> lock(m_mutex);
 
     // Append messages for updated types, fetch them only now.
     enqueueUpdatedTypes();