[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    [Calligra] 4f964e6 Checked KisBaseNode for the thread-safety
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2010-12-13 21:24:14
Message-ID: 20101213212414.2DC6FA60BE () git ! kde ! org
[Download RAW message or body]

commit 4f964e659a5f5ee10f9e768917f8ad1a1e1803d4
branch master
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Mon Dec 13 23:59:51 2010 +0300

    Checked KisBaseNode for the thread-safety
    
    It sounds like the couple KisBaseNode+KoProperties is thread-safe here.
    Though it isn't officially supported by Qt, but our environment is
    very soft (one writer + many readers, only existent keys of QMap can
    be written), so it works.
    
    Added a warning message to the KisBaseNode stating that.
    
    CCMAIL:kimageshop@kde.org

diff --git a/krita/image/kis_base_node.cpp b/krita/image/kis_base_node.cpp
index d375e98..2262716 100644
--- a/krita/image/kis_base_node.cpp
+++ b/krita/image/kis_base_node.cpp
@@ -37,8 +37,18 @@ public:
 KisBaseNode::KisBaseNode()
     : m_d(new Private())
 {
+    /**
+     * Be cautions! These two calls are vital to warm-up KoProperties.
+     * We use it and its QMap in a threaded environment. This is not
+     * officially suported by Qt, but our environment guarantees, that
+     * there will be the only writer and several readers. Whilst the
+     * value of the QMap is boolean and there are no implicit-sharing
+     * calls provocated, it is safe to work with it in such an
+     * environment.
+     */
     setVisible(true);
     setUserLocked(false);
+
     setSystemLocked(false);
     m_d->linkedTo = 0;
     m_d->compositeOp = COMPOSITE_OVER;
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]