@Disco thats what you get for choosing the subclassing thread approach

Anyway I leave this repo link here:

https://github.com/DeiVadder/QtThreadExample

I would almost always suggest the worker approach, but if it's a fire and forget function you want to run in parallel, QThread::create it probably the way to go.

@Pl45m4 Calling slots as a normal function directly from main thread, reading/writing from/to a variable of QObject (using mutex of course).

@SimonSchroeder Thank you! That is really good advice, I will try it out now :)

Drag and drop has never worked very well in QtWebAssembly.
But it is working in 6.6.0beta1 single threaded release.

You need to use asyncify though:
https://doc.qt.io/qt-6/wasm.html#asyncify

Good news is, you no longer have to rebuild Qt to get asyncify, you just need to add a linker argument.
cmake: target_link_options(<target> PUBLIC -sASYNCIFY -Os)
qmake: QMAKE_LFLAGS += -sASYNCIFY -Os

@Dean21 I just figured this out myself and am just posting in case someone else has the same issue.

My function where I want the timer now looks like shown below:

QObject::connect(&client, &QMMqttClient::onMessageReceived, [this](const QString &topic, const QByteArray &msg) { ui->Alarm_Triggered_Label->setText("Temperature alarm of PSU triggered, HV output disabled for 5 minutes"); ui->HV_ON_OFF_Button->setEnabled(false); // Use QMetaObject::invokeMethod to execute the code in the main GUI thread QMetaObject::invokeMethod(this, "publishAfterDelay", Qt::QueuedConnection); });

And the call to function publishAfterDelay() looks like shown below:

void Widget::publishAfterDelay() { QTimer::singleShot(3000, this, [this]() { client.publishMesage("Alarm_5_min_cooldown_complete", "1"); qDebug() << "timer pinged"; }); }

Hope this helps anyone else.

Thanks for your suggestions, @J-Hilk

@J-Hilk said in Slow application with low CPU usage:

I would suggest emitting a signal, signalling data is processed, and then a mutex guarded getter function, that allows the other thread to access the required data.

I'm not sure I understand what you mean. Should each object have a mutex-guarded getter function? Should the objects be in different threads? In this case, wouldn't the emitted signal get queued?
I'd appreciate it if you could provide me an example and/or some material for further reading.

Another idea that has occurred to me is that I could use two threads, one for processing and one for GUI (this one updated just from time to time). Do you think it would make sense? My concern is that the processing thread must be fast enough to complete its cycle before a new piece of data comes in.
If this is the case, would it be necessary to use a mutex anyway?

@Christian-Ehrlicher It took me a whole day, but I finally understood that you were referring to the fact that exit()/quit() can't be used in the same vein as requestInterruption()/isInterruptionRequested() or terminate().

I first learned about basic QThread semantics so long ago (more than a decade I think), that the fact that it's possible to not understand that got completely lost on me.

@Uriel-Machado
Hello and welcome.

Before you go any further: since it is a Qt rule you must not access any UI stuff in a secondary thread --- quite apart from the need for mutexes --- what do you think you are going to access in RadarGUI from a thread anyway?

Threads can send signals to advise the UI thread of something happening and the UI thread can perform the UI action for them.

@kuzulis Thank you so much for your response. That is a great idea.
But you are right, the communication protocol would make a lot more sense if it followed the <length><data><crc> structure.

@JonB 's Idea works well with my existing Program structure.

@JonB It is InheritPriority It was a mistake from my side. Yes, I think you are right, I will have to go to the caller for that. Thanks!

@JonB I'm not using it actually, i tried it, but i also figured that using Qt's own thread management works just fine in this case.

@alan02011114
I don't understand what your question is. As the error message tells you, your slot requires a dfreceived/second position argument and you are not supplying it in your lambda so you get the error.

I changed the destructor code of RTLSClient to

RTLSClient::~RTLSClient() { workerThread.terminate(); if(!workerThread.wait(3000)) //Wait until it actually has terminated (max. 3 sec) { workerThread.terminate(); //Thread didn't exit in time, probably deadlocked, terminate it! workerThread.wait(); //We have to wait again here! } }

now app not showing ..QThread: Destroyed while thread is still running but it not responding when opening

@Christian-Ehrlicher @JonB Solved . By creating a seperate worker.cpp file and connected RTLSClient signal to worker slot, now data is inserting to mongodb very fast without freezing GUI.
Thanks ..

@jsulm @Christian-Ehrlicher signal/slot method working

connect(this,&MainWindow::starting,onethread,&myThread::recvNum); onethread->start(); for(int i=1;i<5;i++) { emit starting(i); }

Hi and welcome to devnet,

From the looks of it, you are likely accessing the QPushButton directly from your custom thread which is forbidden. GUI element manipulation shall happen in the main thread.

to continue the point @Christian-Ehrlicher mentioned above, blocking serial tasks usually exist on server daemon applications, but not on anything with user interaction or a GUI.

@duckrae List your client with id, when you are getting new incomingConnection. server can reply as per client id to a specific client or reply to all.