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

@duckrae said in How to write another Thread data in txt file?: How can I handle it? Simply emit the signal: QTimer *timer = new QTimer(this) timer->start(60000); emit myTimeoutSignal(text);

@duckrae First remove all that thread stuff

Hi, Please use coding tags for your code, that will make it readable. You are using several different instance of sps2data that are unrelated to each other. On a side note, you should always instanciate QXXXApplication before any other QObject based classes.

Hi, In addition to @Christian-Ehrlicher, what exactly are you trying to achieve ?

@jsulm I just now noticed this when I was debugging the code and was about to update here but I see u have already answered it. Thanks

Thank you for your advice. I did as you said and it seems it's working well.

@Dariusz Can you help with the solution that you did to solve the cmake error that you were getting : CMake Error at C:/Qt/6.1.0/msvc2019_64/lib/cmake/Qt6/QtFeature.cmake:1017 (message): Feature poll_select is already defined and has a different value when importing features from Qt6::Core. I am getting the same error when I moved to Qt 6.1. Using the static libs of Qt, built from source.

@Dariusz said in How to properly delete threads& objects in them ?: So in general, moving object to another thread does not set the thread as it parent does it. No because the function is called moveToThread and not moveToThreadAndDoOtherStuffLikeSettingaParent

@SGaist said in QTimer & Thread, adding it to running thread...: With only bits of your code it's not possible to understand your implementation and the possible issues you might be facing. Today is special day for my brain and I literally fail at basics... I forgot to start the worker... thus its event loop never run... thus it never started the damn timmer... ehhh!!!! Everything works fine once I started the worker... yayyyy I learned something new! :- )

My dumb ass set the socket thread to nullptr 1 function before and then I was scratching my head why thread() was retuning QObejct(0x0) and I could not test against nullptr/etc... I'm gifted Sorted.

Humor me, will you? constexpr int poolSize = 16; QVector<QThread *> threadPool(poolSize); QCoreApplication * app = QCoreApplication::instance(); for (size_t i = 0; i < poolSize; i++) { QThread * thread = new QThread(app); thread->start(); QObject::connect(thread, &QThread::finished, thread, &QThread::deleteLater); } QObject::connect(app, &QCoreApplication::aboutToQuit, [threadPool] () -> void { for (QThread * thread : threadPool) { thread->quit(); thread->wait(); } }); int index = 0; for (const QString &video : videoFiles) { ThumbnailExtractor *extractor = new ThumbnailExtractor(counter, folderPath + '/' + video); extractor->moveToThread(threadPool[index++ % poolSize]); QObject::connect(extractor, &ThumbnailExtractor::finished, extractor, &QObject::deleteLater); QMetaObject::invokeMethod(extractor, &ThumbnailExtractor::generateThumbnail, Qt::QueuedConnection); } A note here: QMediaPlayer and related classes don't seem to be reentrant so you can't use them from different threads. Stick to the main one.

Hi, You can connect the "finished()" signal to a slot and there check if all threads are not running. I assume that you have a list of threads.

@CJha said in How to use full processing power available to do calculations?: If I use more threads by using QtConcurrent::mapped() or QThreadPool from inside a non-GUI thread, will it use this non-GUI calling thread as well? To make my point more clear: Let's say I create a thread called A and based on the number of cores my CPU has I have thread B, C and D available. After my thread A calls either QtConcurrent::mapped() or QThreadPool to start the calculation it has nothing more to do till the calculation finishes, so will it wait idle while my calculations are running in other threads or will QtConcurrent::mapped() or QThreadPool include thread A along with B, C and D to do the calculations? We need to know: How do you create thread A? QtConcurrent uses the global QThreadPool behind the scenes. If thread A is not part of the pool, then it won't be used by the pool to do calculations when it is idle. Is there any way I could run a single loop (major loop of my calculation) in multiple threads with different data sets without using QtConcurrent::run()? QtConcurrent::mapped() will not work as it has requirements that there should be a return type which is not always the case with my calculations. QThreadPool, QRunnable and especially QThreadPool::globalInstance() documentation is not enough for me to make this judgement. QtConcurrent::map() (not mapped()!) does not return any values. You can interface with it using QFuture<void>. See https://doc.qt.io/qt-5/qtconcurrentmap.html#concurrent-map Finally, is there a better/simpler approach to solving this problem? Experiment with QtConcurrent::map() and see if it suits your application. NOTE: I have placed the same question in Stack Overflow as well. As a courtesy to other users, please link your duplicate questions to each other. This way, people can see if your question has been resolved and get the answer too

Install a Qt message handler, set a breakpoint in there and take a look at the backtrace where it comes from.

@Cocojambo said in Load balancing between several Threads: I mean that all 4 new threads may be created in one core and we won't get any benefit of such multi threading. You can't with Qt. But the OS will for sure not put all four threads on one core and leave the other three idle when the four have something to do.

Looks like you are re-implementing tools that already exist for that purpose. Was tmux/xpanes considered ? In any case, before doing any threading, you should have a proper encapsulation for your connection and command sending. Once you have that you can start thinking about threads or maybe use QtConcurrent. It looks like you rather have lists of commands to send to machines. A bit like what ansible manages for you with its playbook.

That question is being answered on this thread.

@mvsri said in QT QImage Read From Error: image_path is nothing but a QString which stores the path to a bmp image in a folder. the path is static it doesn't change. I know that! My question is about the content of that file. I don't know whether the image writing is finished or not. that's why i used QFile exists to check if the file is created or not and read the image if the path exists. But that doesn't tell you anything about whether it has started but not finished writing to that file, does it? (Unless you are relying on Windows or something not allowing a file to satisfy "exists" until it has been closed, which I would see as dodgy in the extreme.) In which case, you will read in an incomplete image file, maybe that's why you have "black" at the bottom? At least put in a qDebug() << image.sizeInBytes() after loading it (though I'm not sure if that's reliable).... QFile::remove(image_path); It gets worse! This, or renaming: how do you know that at the instant you execute this the camera has not re-started writing to that file for the next capture, and you are (trying to) removing/renaming a file while it is being written anew? Is your camera-image-capture-write-to-file a separate process from your code? How do you know when the capture has started/finished writing to the file?

Congratulation and thank you for the fix :-)

By the way, how are your buttons connected ? You might want to rather call the dialog's accept slot from on_buttonBox_accepted rather than connecting it directly to your button.

Can you share the code you are using ? Do you get any warning about a timer being in the wrong thread ?

@jsulm: Thank you for your reply. The part I missed is "The default implementation simply calls exec()." @J.Hilk: Thank you for the great set of examples. IMHO, this should be placed in the QThread Class Documentation.

@Bonnie said in QThread does not quit, why?: The solution is QObject::connect(myControl, &Control::finished, myThread, &QThread::quit, Qt::DirectConnection); And where does it say that this slot is thread-safe? @robro Just quit the thread before you exit the application. QObject::connect(&app, &QApplication::aboutToQuit, myCtrl, &Control::deleteLater); QObject::connect(myCtrl, &Control::finished, &myThread, &QThread::quit); QObject::connect(&myThread, &QThread::finished, myCtrl, &Control::deleteLater); //< This is needed Which translates simply to: qDebug() << "Started Waiting:"; myThread.quit(); myThread.wait(); // Wait for thread to quit qDebug() << "Quit";

@Christian-Ehrlicher Thank you very much! It solved my problem perfectly :)

@TMJJ001 said in QTimers and QThreads: connect(&cThread,SIGNAL(started()),this,SLOT(DoWork())); You do NOT execute DoWork() in that thread, you execute it in the GUI thread. Take a closer look at the example here: https://doc.qt.io/qt-5/qthread.html