@davidesalvetti Hmm, I am not very confident in your solution. I would create a helper class to create/use right connection according to current thread.
Something like this (it is just a skeleton, not sure it is working as it is):

#include <QSqlDatabase> #include <QThread> class MyBDConnection { QString m_dbPath; QString m_dbName; Q_DISABLE_COPY(MyBDConnection) public: explicit MyBDConnection(const QString &sqlitePath, const QString &cnxName): m_dbPath(sqlitePath), m_dbName(cnxName) {} QSqlDatabase getDBConnection() { // Starting with Qt 5.11, sharing the same connection between threads is not allowed. // Use a dedicated connection for each thread requiring access to the database, // using the thread address as connection name. QSqlDatabase cnx; QString dbName = QStringLiteral("%1_%2").arg(m_dbName).arg(qintptr(QThread::currentThreadId()), 0, 16); if(QSqlDatabase::contains(dbName)) { cnx = QSqlDatabase::database(dbName); } else { cnx = QSqlDatabase::addDatabase(QStringLiteral("QSQLITE"), dbName); cnx.setDatabaseName(m_dbPath); if (!cnx.isValid() || !cnx.open()) { qDebug() << "DB connection creation error!"; } } return cnx; } }

And the only create on instance of this class and pass the pointer to each class which need connection to DB.

@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?

@SGaist : I am using Windows 7.....

Thank you all very much :-)

I tested both and both works fine.
The QMetaObject::invokeMethod is really convenient :-)

@stvokr

From experience:

Your first assumption is incorrect:
/* Thread not started, Mutex is not necessary */
What if someone calls startThread() after the thread is started (it is not correct, but can and possibly will happen)... So fist check m_run before going on to start the thread.

Make the intention clear: Either make m_run atomic using either Qt atomics or C++11 atomics or protect it with mutexes wherever it is used. Then you do not need to worry about the way that it is implemented on the specific compiler. If it is really timing critical code then you can start to worry about the additional overhead. From a maintainability and readability point of view it is then easy to know that the variable in question can be accessed from other threads. From my understanding reading is mostly atomic, thus you do not need the locking for the read.

Mark the variable as volatile.

[edit]
To answer the second question:

Is it even necessary to use a mutex when a variable will only we written by one thread while other threads only read this variable?

If you can guarantee that this will always be the way that it will be used then it should be ok. So if you are the only one developing on the code, and that will use the code perhaps you can. But if you share the code or need to re-use some parts down the line (in a few years perhaps) you might not remember that there is such a limitation. Rather safe than sorry.

I hope this helps a bit, someone else might have better insights.

SOLVED updating the client to Qt 5.5.0

I solved this.
I moved everything related to the serial port into a separate class SerialWorker and moved it to a separate thread.

QThread* serialthread = new QThread; SerialWorker* serialworker = new SerialWorker(); serialworker->moveToThread(serialthread); connect(serialthread, SIGNAL(started()), serialworker, SLOT(InitSerialPort())); serialthread->start(); connect(serialworker, SIGNAL(NewProto(QByteArray)), this, SLOT(ProtocolInterpreter(QByteArray))); connect(this, SIGNAL(SendRS(QByteArray)) , serialworker, SLOT(writeData(QByteArray)));

This works as supposed. Serial port is now more or less very responsive.
WebKit is still blocking the GUI thread sometimes but thats not as much an issue as the serial port not responding.

Inter-thread communication is not an easy matter to be done properly.

No you don't, check the worker object paradigm of QThread's documentation

I'd like to add:

Specially if the Watcher needs to be used multiple times it's important to disconnect it after use:

disconnect(FormatWatcher, SIGNAL(finished()), this, SLOT(FinishedFormat())); // disconnect former slot used with watcher

@JKSH

Thank you very much I think now I understood it. Thanks for the help.

@koahnig actually the project is using lots of locally compiled libs so a "quick" recompiling is not a possible solution to try out (qt uses different compiler with version newer than v5.2).

However, once getting back to my problem I tested some debug config checkboxes and it turned out that the debug helpers were the "problem". Turning off showing thread names did not cause the debugger to stop deep in qt code several times anymore.

In the end it is a pity not understanding what is going on when ticking that config option, though I am glad getting back to debugging now!

How can i create my signal for text edit with python3 ?
With as many ways i tried, but I did not succeed .. :(

@JKSH
Oh, did not catch that difference. Thank you.

@Leonardo said:

nections, the parameters must be of types that are known to Qt's meta-object system, because Qt needs to copy the arguments to store them in an event behind the scenes.
...
Call qRegisterMetaType() to register the data type before you establish the connectio

Wow, that really helps!

Thank you so much!

I will try it right now

@Jeroen3
Thank you for your sharing!

@stereomatchingkiss Indeed, such a huge amount of connections in such a short time would rather need a thread pool, otherwise you're going to starve your system.

OH yes. thread without run...
thank you.

Hi @rkhaotix,

I had a quick look at your code. It's too big for me to go through properly, and I didn't spot anything obvious that maxes out your CPU.

However, I noticed a few things which might be related:

Your ModelExportHelper constructor is run in the main thread, so it opens the DB connection in the main thread. Are you sure you can use that connection in the worker thread after this? In line 56 of modelexportform.cpp: the lambda runs in the signalling (GUI) thread, not the worker thread. Note that, while the QThread manages the worker thread, the QThread object itself lives in the GUI thread. Your ModelExportHelper uses some GUI-related classes: QGraphicsView, QPixmap. These classes must only be used in the GUI thread. Your ModelExportHelper includes "modelwidget.h". Why? Widgets must only be used in the GUI thread.

I have shown only a simplified version of my code.
Actually I have lots of networking happening serially and parallel.
I transferred all of this to a new thread so as to keep my GUI thread free.
Thanks for your advice!