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

Thank you very much

@David.G said: Thanks for the reply, @JKSH. I've been wondering, I'll remove the code of forever {}, what would be a way to constantly poll if there's data to process? Should I just use a timer every 1 second to keep poking the process method with a simple boolean that returns if process is already running?. You're welcome. :) Yes, using a timer is a good way to poll.

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

You're welcome ! If that answers your questions then please update the thread title prepending [solved] so other forum users may know a solution has been found :) Also, consider up voting the answer(s) that you find useful, it will help others to find them more easily :)

You're Welcome

@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

#2 is wasteful way indeed! but in low baud rates it will help, but in this case I don't think this is a low baud rate. EDIT : I said for example 1ms, you really don't need it this fast, it depends on the frequency of getting bytes, for example for 20Hz you will have 20bytes every second which means you need a timer with at least 50ms refresh time and of course you read from serial port in asynchronous way then you can't 100% trust this way to read byte by byte, So as @JKSH said you better don't use this way if you don't have a specific reason.

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

@SGaist Thanks for the link! I'll check it!