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

List:       kde-kimageshop
Subject:    Usage of setCurrentNodeLocked()
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2010-09-21 6:20:15
Message-ID: AANLkTikRfwyyOoQvKL5yDZ6JOm5kpS8WingJs=G_re_E () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi, All!

I found that some of the calls to setCurrentNodeLocked() are done in a wrong
way. I mean, at least in KisToolFill and KisToolGradient there is a
possibility that the codepath will return from the event function and leave
the node locked forever.

I do really think we should remove all these workaround "locks" and handle
our tools in a proper way. Because these subtle locking bugs are really
difficult to see and catch. I think it's better to delay the release if
needed, than to release a product with random bugs.

-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

Hi, All!<br><br>I found that some of the calls to setCurrentNodeLocked() are done in \
a wrong way. I mean, at least in KisToolFill and KisToolGradient there is a \
possibility that the codepath will return from the event function and leave the node \
locked forever.<br> <br>I do really think we should remove all these workaround \
&quot;locks&quot; and handle our tools in a proper way. Because these subtle locking \
bugs are really difficult to see and catch. I think it&#39;s better to delay the \
release if needed, than to release a product with random bugs.<br clear="all"> <br>-- \
<br>Dmitry Kazakov<br>



_______________________________________________
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]