@Kirill-Gusarev See @SimonSchroeder explanation and also read https://doc.qt.io/qt-6/threads-qobject.html

@MH24 I don't know but a thread will (when it would work) also not speed it up.

You can pre-compute the BMP in a separate thread and then access the finished image in the main thread to use it in the splash screen.

Hi, What kind of popup are triggering the freeze ?

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

@gd2shoe Thank you for this detailed, comprehensive, and correct post! As far as I can see, everything you've written is correct. I can't see anything important that you've left out. the Qt "main thread" is the first thread to create a QObject instance. ... Only one QCoreApplication instance can be created at a time (or it's derivatives). It should be created in the Qt "main thread" (which should also be its thread affinity). Its exec() function starts the main event loop, and should be run from the Qt "main thread". Bingo. These are the core points from which everything else derives from. There is one more implication: If we want to destroy the QCoreApplication and create another one (without unloading the libraries from the process' memory), then we must keep the original "main thread" alive and create the new QCoreApplication in that same thread. Shutting down the original "main thread" means that we cannot create any more QCoreApplications in this process instance. Currently, the formal documentation is incomplete, and somewhat inaccurate/misleading. Hopefully that will be rectified at some point. Would you like to have a go at correcting it? (Both the documentation and the runtime warning, "WARNING: QApplication was not created in the main() thread.")

That question is being answered on this thread.

@Lior said in Signal inside readyread of QUdpsocket: why the UI main thread stoped to respond ? the msleep is in anthor thread. Because you do it wrong (and I would guess the msleep is not in the thread but in the gui thread) but without code...

Rather than having both your PLCs competing to write in some global structure. You should rather have them independently fill each their own structure and have some sort off watchdog switching from one or the other if needed. Depending on the how often the PLC are supposed to send data, you should maybe consider restarting the network check when you receive data rather than having that again competing with incoming data.

Hi @YenZi A little bit late, but could using a Loader and settings its asynchronous property to true work? http://doc.qt.io/qt-5/qml-qtquick-loader.html#asynchronous-prop

@jsulm It's alright. I ended up going completely asynchronous by using a chained callback structure. Thanks anyways for the help!

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.

@moffa13 said in Slot called multiple times to a blocking function in the same thread: One question : Is it bad to lock and unlock a mutex multiple times ? No, that's exactly what they are deigned for

@panosk and to be honest I had already started work on this You already have that in QSqlDatabase, you only need to keep track of the connections' names. Good luck!

Hi and welcome to devnet, What backtrace do you get from the crash ?

Hi and welcome to devnet, Are you also new to coding ? If so, then don't start with threads, that's a pretty complex subject that you should take on later after getting the basics correctly. Also, for what you described there's no need for threads. Qt's asynchronous nature already provide what's needed. Start with Qt's documentation. It also contains the Threading Basics On a side note, it's Qt, QT stands for Apple QuickTime which you might also be interested in.

@Kourpetis Hi, it sounds like your code is getting stuck in your while loop. I believe your code needs threading.

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?