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

indexing by Google worked. :-) In a µC emulation project, where i want to change the emulated program as little as possible, i 'secretly' start a c++ thread on which i create and run the QApplication, but it fails with the "not the main thread" message. With the insight from your article i realized that creating two static QObjects during static initialization phase caused the problem. Replaced them with pointers, and: bingo, it worked. Thanks a lot for this article!

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?