Thread operation question

[Maurizio Berti]

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/bd3875d4/attachment.htm>