Once more: Threads in Qt4

[high_flyer]

Since I need to write a server client application where the clients run in their own thread I started reading about threading in Qt4.
In Qt4 as opposed to Qt3, QThread has its own event loop, that can be started with exec().
According to docs:

int QThread::exec ()
Enters the event loop and waits until exit() is called or the main widget is destroyed, and returns the value that was set to exit() (which is 0 if exit() is called via quit()).
It is necessary to call this function to start event handling.

and

Having an event loop in a thread makes it possible to connect signals from other threads to slots in this threads, using a mechanism called queued connections.

And here is what I don't understand so well:
Once exec() is called, run() is "halted" on that spot till quit() or exit() is called, which means, that I can't have a thread run an endless loop AND receive signals from other threads (i.e running an event loop) by means of processEvents() or similar.
The only solution I see is to create yet another object with my thread that will run my work loop, while my "parent" thread object runs the event loop...
But I tend to think I am just not getting something right here, which is why I am posting this :-)

Comments and explanations are more then welcome.

Thanks.

[Chicken Blood Machine]

This may not be the best solution, but I think you should consider the exec() event loop as your infinite loop. You can carry out your task, by setting up a QTimer with a timeout of '0' and connect it to a slot that does the work,. After this your job will be repeatedly processed by the event loop.

[Conel]

Once exec() is called, run() is "halted" on that spot till quit() or exit() is called, which means, that I can't have a thread run an endless loop AND receive signals from other threads (i.e running an event loop) by means of processEvents() or similar.
The only solution I see is to create yet another object with my thread that will run my work loop, while my "parent" thread object runs the event loop...

Yes, you are right. You may only choose between running your own loop and perform some work (in run() method) or running event loop (invoking exec() method).

The solution you mentioned is the usual sort of things, but it does not solve anything :-). You have main thread where you invoke app.exec(). But before calling exec() you usually create other thread and start it. Suppose that you are running your own loop (not invoking exec()). In this case new thread is considered as a usual object which can receive signals, but the slots of this new thread will be executed in the main thread (generally in the thread where you created your child thread and connected signals to the slots)

But why do you want to pass signals to your child thread? If you want to pass any information to your child thread without any event loop I'm afraid you will have to do this via members of the child thread object (using mutex, of course)

[high_flyer]

But why do you want to pass signals to your child thread?

My thread is fed with information which it then needs to work on, and propagate the result to other threads.

You can carry out your task, by setting up a QTimer with a timeout of '0' and connect it to a slot that does the work,

Yes I thought of it too.
I guess timeout '0' is a bit too risky, in case it gets activated before exec() is executed, but few ms would do I guess, I just think this solution looks bad.
I guess I will just resort to the old Qt3 custom events method, unless someone here can explain the advantages of Qt4 signals/slots over threads...

Thanks.

[Chicken Blood Machine]

Yes I thought of it too.
I guess timeout '0' is a bit too risky, in case it gets activated before exec() is executed, but few ms would do I guess, I just think this solution looks bad.

It's not risky. The timeout is not going to fire until the event loop runs (exec() is called). That's the whole point.

[high_flyer]

good point!