<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
For now, I think the systemlocked mechanism is a working option</blockquote><div><br>Well, can you proof it? I mean can you proof it works theoretically, without running Krita and life-testing it with a couple of mouse clicks? Why do i ask? Because in multithreaded and asynchronous environment (our threading + Qt's quasi-asynchronous signals) life-testing can easily show no bugs. As for me, i can't proof it.<br>
<br>All i can tell about this, it may have really subtle, rare, difficult to reproduce and catch bugs, like:<br>1) Race conditions between threads reading/writing a global variable KisBaseNode::systemLocked().<br>2) Race conditions because of quasi-asynchronous signals due to processing the queue in KoProgressUpdater<br>
3) In it's current state, not all user actions are covered by these locks (like all the methods from KisImage), so they do not solve the problem. More than that, i can't even tell what will happen, if you add this to KisImage, because some of the methods of the image work with several nodes. And, you know, the place where at least two locks appear is a weird place. And, taking into account this "lock" is a variable, instead of a stack (a stack or a counter should be used for a reentrant lock), the state of the variable can easily become undefined.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">, but as you say, we are doing it in the wrong way. We could have a KisNodeLocker object that's created at the start of the option on the stack and on deletion (when the action method ends) should unlock the node, instead of manually locking and unlocking. That is a relatively small change that will help a lot.<br>
</blockquote><div><br>That may fix only one problem of a set of bugs. We should fix the root of the problem, but not it's consequences.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I know you would prefer a queuing mechanism, and I still sort of agree desktop Sven's objections, but it needs really careful designing since then every non-interactive action (like fill, filter, gradient, scale) needs to be encapsulated in a job and the job put on a queue.<br>
</blockquote><div><br>Yes, but it can be easily proofed and unit-tested, in contrary to the systemlocked approach.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
And there would still be a clash with the paint tool, since I don't think that its actions should be mixed in the queue with the long running actions. And it might still be better usability to disallow starting a new gradient while the old one is running, for instance.<font color="#888888"><br>
</font></blockquote><div><br>I think there is nothing bad in adding all the tools and actions to the same queue in case the queue has good barrier abilities.<br> </div><div><br>PS:<br>
Btw, our swapping mechanism started to work only a semi-formal proof. The
proof that it will not block and all the operations will be performed
in a finite number of steps. Before that it was constantly crashing and hanging
up.<br>
<br clear="all"></div></div><br>-- <br>Dmitry Kazakov<br>