Thread operation question

[Luca Bertolotti]

Hello
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.
regards
Luca

Il giorno ven 4 lug 2025 alle ore 00:39 Maurizio Berti <
maurizio.berti at gmail.com> ha scritto:

> Ciao Luca.
>
> Il giorno gio 3 lug 2025 alle ore 17:03 Luca Bertolotti <
> luca72.bertolotti at gmail.com> ha scritto:
>
>> Hello i have a question about thread management
>>
>> In my project i have  define a class
>> [...]
>> 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?
>>
>
> Well, your code has some serious problems to begin with: despite your
> attempt to move the "self.read_pos" instance to another QThread, it's not
> using threading at all.
>
> When dealing with threading and Qt threading it's important to be aware
> about some aspects:
> - the thread in which every object may "live" and "work";
> - QThread (as much as a Thread instance from the threading Python module)
> is not "a thread", it's an interface to the system threading management;
> - only objects created in the "run()" 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);
>
> The "read_pos" instance of the "Read" 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.
> The fact that you then call moveToThread() 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 ***no*** 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.
>
> Creating the timer with the "self" argument (pointing to the "Read"
> instance) would theoretically fix that, but then we'd have another common
> issue: the connected "leggo_x_y" function attempts to access an UI
> element, and UI elements are ***not*** thread-safe: they should ***never***
> 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.
>
> Besides, you've never called the thread's "start()", so you are really
> not using threading to begin with.
>
> 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?
>
> 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.
>
> That said, I'm under the impression that you may have a classic XY problem
> <https://xyproblem.info/> ("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?
>
> Regards,
> MaurizioB
>
>
> --
> È difficile avere una convinzione precisa quando si parla delle ragioni
> del cuore. - "Sostiene Pereira", Antonio Tabucchi
> http://www.jidesk.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20250704/a9687855/attachment.htm>