[Qt-interest] Multithread (local objects in QThread requesting GUI updates)

[Cristiano Leorato]

In the classical QThread examples in the Qt documentation, there are
essentially two classes:
- A, a GUI class
- B, a QThread, which does the time-consuming work and emits a signal when A
shall update the GUI

So far, so good.

As a side note, the default Qt::Autoconnection (in connecting B to A) is
actually translated as Qt::DirectConnection, because B "lives" in the same
thread as A.


In less trivial cases, B needs to delegate the computation to local objects.
For example, in the B::run method, an object of class C may be declared and
invoked to do part of the job.
In this case, while doing its computation, C may also want to tell A to
update the GUI.
What is the right way to achieve that?

Some possibilities:

1- To have C calling directly the B method which emits the signal. I think
this is unsafe,
because C really "lives" in the new thread, which means that the GUI event
loop may be executing operations
(e.g. the main thread may already be updating the GUI)
while C calls directly B. For example, even crashes are possible.

2- To add a second signal from C to B.
In this case, as B and C "live" in different threads, Qt::AutoConnection
will be interpreted as Qt::QueuedConnection,
so I am ensured that the slot updating the GUI will be called safely.

Is my understanding correct?

Are there better ways? (it seems a bit ackward having to treat one logical
event through two connects, i. e. from C to B and then from B to A).

Cristiano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100314/ba1f4972/attachment.html