@sebs What I don't understand: you want an application with 3 threads, right? But why do you create new process?

Hi,

The terminate as it names suggest kills the the thread so it's state is not guaranteed as mentioned in the documentation.

Not that you are automagically destroying everything once your operation is done. See your connections to the deleteLater slots.

Hi @Andrea

WOW! Infinite loop to just sleep and process events. Why not just start a timer of PreciseTimer and allow the events to flow freely in the thread? Since you want it to run as fast as possible you can even set the timeout to 0 to run freely when there are no events.

You can then look at thread->requestInterruption () and the thread will comply! Just make sure if you are doing something in a loop in the timer callback you check thread ()->isInterruptionRequested (). And best of all... NO CHECKING THE EVENT QUEUE!

There is a nice writeup about proper thread use at: https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/

You are basically there with your code. Just the loop is wasteful.

@SGaist
Thank you for your answer!

Hi and welcome to devnet,

You can use a proxy model that adds the columns you want/need.

You can keep updating the DB content and trigger the GUI update at some known interval or when a certains amount of changed happened to the database.

Ok, thanks, I think I have all information I need now.

@diverger As @micland already explained this does not have anything to do with Qt. It is a general problem with multi-threading: if you call a method from an object which leaves in another thread then you have to make sure this does not cause any problems.

@VRonin
Thanks for your input - there seem to be some misunderstanding.
I can not and do not want to wait for the acknowledge of the server as a trigger to sent the next log message - this is against the idea.
Log messages need always to be sent, regardless wether the server acknowledges or not - imagine the server even does not acknowledge.

Every message sent has an ID# that is incremented by one for every new log message sent.
The server acknowledges every message with returning the ID#.

Looking at the network of the server with Wireshark and having incoming log messages with time stamps of the same msec - obviously the server has no time to send the acknowledge between incoming protocols. I.e. Sending #1 and # 2 in such a short sequence, obviously when sending #2 the counter for a missed message goes up to one.
This is inherit by this system and is by design.

Therefore, I'm going to implement a gap of at least a few msec between sending messages.
Because the messages are all handled and forwarded in the application by signals / QtEvent queues, I dont have a solid idea so far how to do this.
I may have to create a time gated sending queue before handing the messages over to the signal and the QtEvent queue.

Yes i did.

And with that clue i figured it out! QApplication::desktop()->screenGeometry(screenIndex); works like a charm.
Tyvm!

@VRonin
Server is on a different machine in the LAN and the software is not from me.
I only implement the client side.

@SGaist said:

mkspecs/device/linux-rasp-pi2-g++

Shouldn't it maybe be mkspecs/device/linux-rasp-pi-g++ (without the 2)?
In his makefile there is this line:

INCPATH = -I../threadtest -I. -I/usr/local/qt5/mkspecs/devices/linux-rasp-pi-g++

Hi,

What about doing the subscription related stuff in your proxy ? Basically two methods:

FeedProxy::subscribe(YouCoolClass *) FeedProxy::unsubscribe(YouCoolClass *)

No need for any special detection and you know exactly where things are happening.

@SysTech

Thanks again!

You're very welcome.

Those 3D displays are kind of handy for visualizing the radio output but they are right now pretty CPU intensive.

If I may insert yet another suggestion here. While I don't believe you'd gain much by using OpenGL painting for the "waterfall" data, I think switching to it for the 3D displays would work better. I nice side effect would be that you can also render OpenGL from different threads, provided the appropriate locking mechanisms are in place. You could, as the most simple test, try using QOpenGLWidget for those FFT displays.

Kind regards.

@SGaist I don't mind refactoring it, it's not very long. I will definitely look into this. Thanks!

You're welcome !

Since it's all clear now, please mark the thread as solved using the "Topic Tool" button so that other forum users may know an answer has been found :)

@zzaj
No problem. Good luck with your project!!

Hi,

I haven't used that class but from the looks of it, using the worker object approach should be fine.

There's no multi-threading involved here whatsoever. All code here runs in a single thread (unless the timer object and "this" actually live in different threads).

There's an event loop running in your app and timer events are just the same as any other. They get put in a queue and processed one after another.
The above will basically mean that your slot is run every time Qt processes messages. It can have very bad influence on your app responsiveness if what you do in the slot is heavy.

The most obvious question is: if you want a thread why not use an actual QThread instead of emulating it like that?