[Qt-interest] Is it "bad" to call a blocking function of Thread B directly in Thread A?

[K. Frank]

Hi Sven -

On Wed, Oct 6, 2010 at 7:33 AM, Sven Grunewaldt <strayer at olle-orks.org> wrote:
> Hi,
>
> let's assume I have two classes, Producer and Consumer. Both of these
> classes run in their own QThread. Now I want to call a blocking function
> of Producer within Consumer (via a pointer to the instance).

First, to be precise, we should distinguish between a thread of execution and
an instance of a QThread object.  The two are connected in that a QThread
object manages a thread of execution, and a QThread object has (as do all
QObjects) "affinity" for a thread of execution, and this affinity
determines which
thread executes the QThread's slots.

A big source of confusion is that the thread of execution managed by a QThread
and the thread of execution for which the QThread has affinity are not
necessarily
the same, and, in fact, are usually different.

I assume that you mean that you "have two [instances of] classes, Producer
and Consumer" that are QThread objects, i.e., derived from QThread

AND

that the bulk of the processing done by each of these instances is carried out
in the thread of execution managed by the instance in question.

> There is no possibility of two Consumers trying to access the same
> Producer at the same time and stuff like that. Only one Consumer and one
> Producer.
>
> I tried this with a simple testcase and it seems to work:
> http://pastebin.ca/1955512 (Sorry for the Windows.h and Sleep() )
>
> I think I could achieve the same thing with Signals/Slots and
> QWaitCondition, but since there are only two instances and no real
> concurrence this looks way to complicated.
>
> Is this in some way dangerous, very bad practice, not portable, etc.?

It is not "bad" to call a member function of a QThread object from
either a thread
of execution that is not managed by the QThread or from a thread of execution
for which the QThread does not have affinity.

After all, member function are just functions, and functions get
called by whichever
threads of execution decide to call them.

Technically, this is just fine.

There are some caveats:

You might consider it bad style (I don't) if your project team isn't
expecting this
"cross-thread function calling" and finds it confusing or if it is
proscribed by your
coding standards.

If the function might be called by more than on thread at the same
time, it needs
to be thread-safe, just like any function.

If the function emits a signal, the signal is emitted by the calling thread (and
neither by the thread managed by the QThread nor by the thread for which the
QThread has affinity).  There's nothing wrong with this, but it may
cause confusion
if you don't bear this in mind when analyzing which thread of
execution will execute
the receiving slot.

Good luck.


K. Frank