Progress update and action cancel architecture

[Thomas Zander]

On Tuesday 27 December 2005 21:56, Boudewijn Rempt wrote:
> This gives problems with threading: if I start four threads and they
> all want to update the progress label, we're in for a rude shock. The
> progress label is broken anyway because it uses processEvents(), which
> guarantees crashes, especially if users are scaling in one view and
> trying to work in another.

I'd like to point out a library I wrote that soles this and various other 
problems.  I did that for java swing, but the issues are similar in Qt.

What I do is start a queue-thread.  This thread holds queue of actions and 
hands them to worker threads for execution.
Actions (much like KActions) had 2 extra methods in my version; an 
execute() and a doAction().  The latter being protected (which in Java 
means that the workerthread can execute it since its in the same 
package).
The execute does nothing but enqueue itself leading it to eventually be 
processed.  This also means that the execute() will return almost 
immediately.

In my action object I did not register one, but 2 slots.  The second is 
optional, and is meant to do UI updating.  The second slot is guaranteed 
to be executed in the normal event thread which means you will never run 
into threading problems if you do your setProgress and stuf in there.
It will only be called ones though, after the primary slot has returned.

All the other UI updates (like the progress display label) should IMO 
simply be wrapped in C++ equivalents of a synchronized(canvasView) { } 
block, where the canvasView is an object that makes sure only one tread 
is using the KoView at a time.

Hope this makes sense; you can browse the java based solution and its docs 
on http://uic.sf.net/index.phtml?target=product/Actions/view.phtml
Note that that framework has many many features that I really would like 
to see Qt or KDE have, so you kdelibs hackers, please also take a peek to 
see what the competition has been doing :)

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20051227/7e8af069/attachment.pgp