<div dir="ltr">Hello<div>what i'm trying to do is read data from a Servodrive avery 250 ms or if i can less and write the data in the widget where i have button and other stuff.</div><div>regards</div><div>Luca</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Il giorno ven 4 lug 2025 alle ore 00:39 Maurizio Berti <<a href="mailto:maurizio.berti@gmail.com">maurizio.berti@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">Ciao Luca.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 3 lug 2025 alle ore 17:03 Luca Bertolotti <<a href="mailto:luca72.bertolotti@gmail.com" target="_blank">luca72.bertolotti@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello i have a question about thread management<div><br></div><div>In my project i have  define a class </div>[...]<br><div>My question is in order to allow speed and never have latency on the widgets is better to add a signal in the Class Read and connect it to a def in the Class Form and then fill the lineEdit directly in the Class Form or leave as it is?</div></div></blockquote><div><br></div><div>Well, your code has some serious problems to begin with: despite your attempt to move the "<span style="font-family:monospace">self.read_pos</span>" instance to another QThread, it's not using threading at all.</div><div><br></div><div>When dealing with threading and Qt threading it's important to be aware about some aspects:</div><div>- the thread in which every object may "live" and "work";</div><div>- QThread (as much as a <span style="font-family:monospace">Thread</span> instance from the <span style="font-family:monospace">threading</span> Python module) is not "a thread", it's an interface to the system threading management;</div><div>- only objects created in the "<span style="font-family:monospace">run()</span>" override (or implicitly/explicitly moved to the QThread due to parenthood) actually work in the same thread, and most of them can only be accessed from that thread only (including timer objects, which cannot be started/stopped from external threads);<br></div><div><br></div><div>The "<span style="font-family:monospace">read_pos</span>" instance of the "<span style="font-family:monospace">Read</span>" class is created in the main thread, meaning that everything created in its constructor (the "__init__") resides in the original thread as well, including the "self.timer_leggo_x_y_" timer.<br></div></div><div>The fact that you then call <span style="font-family:monospace">moveToThread()</span> is irrelevant in this case, because the QTimer instance was created without any parent, therefore it won't be moved to the new thread: Qt has absolutely **<b>no</b>** awareness about Python, it cannot know nothing about the "timer_leggo_x_y" object, which will remain in the main thread as an arbitrary "orphan" object that will exist only as long as one reference to its related "Read" instance has at least one reference in Python or its parent (if any) is alive in Qt.</div><div><br></div><div>Creating the timer with the "<span style="font-family:monospace">self</span>" argument (pointing to the "Read" instance) would theoretically fix that, but then we'd have another common issue: the connected "<span style="font-family:monospace">leggo_x_y</span>" function attempts to access an UI element, and UI elements are **<b>not</b>** thread-safe: they should **<b>never</b>** be accessed in any way from any thread but the main UI thread. Reading data from UI in separate threads is unreliable, writing it is unsafe; both of them will almost certainly result in unexpected results at the very least, and fatal crashes in most cases.</div><div><br></div><div>Besides, you've never called the thread's "<span style="font-family:monospace">start()</span>", so you are really not using threading to begin with.<br></div><div><br></div><div>On the other hand, it's unclear what you're really trying to achieve, nor what you mean by "in order to allow speed and never have latency on the widgets": what "speed" issues do you have?</div><div><br></div><div>Your code explicitly hides what the "reader" is or does, so it's really difficult to understand what it may eventually do. In any case, yet, when using threading (and, most importantly, when dealing with Python GIL issues), there's fundamentally no way to have "instant" results from a separate thread in case it's too occupied doing things without releasing control to the main thread, which will only react and eventually provide UI results (aka: widget repaint) as soon as the main UI thread gets control back from it. The UI will only be updated as soon as it can: when any other thread releases control and the system decides to give it to the main thread; when that will actually happen is arbitrary, not foreseeable/customizable/deterministic and almost never fully/reliably predictable in case more external threads are in play.</div><div><br></div><div>That said, I'm under the impression that you may have a classic <a href="https://xyproblem.info/" target="_blank">XY problem</a> ("asking a wrong question while trying to fix the wrong issue"). What are you actually trying to achieve, and what issues were you facing in your original attempts?</div><div><br></div><div>Regards,</div><div>MaurizioB<br></div><div><br></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div></div>
</blockquote></div>