Thread freezing GUI

[marcel]

The connect documentation and Qt::AutoConnection state:
"If the signal is emitted from the thread in which the receiving object lives, the slot is invoked directly, as with Qt: DirectConnection; otherwise the signal is queued, as with Qt::QueuedConnection."

Yes, but this connection is made when you call connect, and not derived dynamically, when you emit the signal.

So the connection remains Qt:: DirectConnection, even if you call the method that emits the signal from another thread.

By putting both the signal and the slot in the GUI class, calling a member function of the GUI class to emit the signal (and set some variable) from another thread, I should be getting a queue response because the signal is being emitted from a thread which is different from the one where the receiving object is? Am I reading this wrong, that is certainly possible? Just by virtue of the thread in which the SIGNAL is declared, not called, does that change this? Could I also just set these connections up and force them to be queued, since they are unique? My issue is that I would have create these signals and connections in several threads rather than one set of functions in the GUI thread that could be used by all external threads. I can certainly do this, I just want to be sure it is required?

No, it gets a direct connection. You could try to force it to QueuedConnection when you call connect but I'm not sure if it will work.
Being a DirectConnection, the slot will get executed in the context of the worker thread.
So if any widgets are modified as a result of this slot, the GUI will block.

But why don't you try my suggestion?
Instead of a GUI method call, just emit a signal from the worker thread. The signal should be connected to the slot in the GUI. There aren't that much modifications to be made( actually they are minimal ).
This way you are guaranteed to have a QueuedConnection, therefore no blocking.

I hope you understand.

For other reasons I have been playing with the frequency of the CALLBACKS from ALSA and have noticed that the more frequent the CALLBACKS are occuring, the more quickly my GUI freezes after startup. A 5ms callback rate will freeze within 10 seconds of startup 3 of 5 times. A 10ms callback rate doesn't ever seem to freeze within the first 5 minutes of execution.

Yes, a perfectly good explanation for blocking the GUI. Therefore use a signal instead of calling the GUI thread directly. It is not normal to do that.

Thus my supposition that the CALLBACKs from ALSA, are causing some issue with the GUI thread. I could very well be wrong and your reply may be my issue. I would like to think that it is since I could solve the problem and move on to other work, but it doesn't quite jive with all the data.

No, only the context in which the GUI slot is executed is the problem.

Regards

[dcss-design]

Thanks Marcel,

I hadn't thought about it being more about the connect() and when it was done, than when the signal was actually emitted. Basic flaw in my understanding and reading of the documentation.

I'll give it a try, see what I get, and report back.

Thanks,
Doug

[dcss-design]

Marcel,

Before making the changes you suggested, I did a little testing with the debugger. Turns out my method is just fine for creating signals from other threads. In each case that I called one of the public functions in my GUI class to emit the signal, when the GUI update was actually performed it was in fact performed by the GUI thread, not the thread that called the public function causing the signal to be emitted. This was verified in both Windows and Linux.

I further verified this fact with Trolltech. They stated: "because when the signal is emitted the code in the QMetaObject::activate() will check that the thread that resulted in the emission of the signal is different from the thread in which the object lives. If this is the case, an event will be posted to the event loop of the receiver and will be be processed asynchronously so this is safe."

In any event, I'm back to square one. I rewrote my ALSA routines to be separate threads (one for playback and one for record) that use blocking calls to move the data. Excactly the same external interface to the rest of my application. No GUI lockups now. Even more surprising is that the audio performance and latency is much better.

At this point, I'm going to put this on the back burner and expect I'll find the root cause at some point while doing something else. If I do, I'll post on it.

Thanks for all the suggestions, I certainly learned a lot about some things I didn't know much about before.

Regards,
Doug