Dennis, Thanks for the clarification.
Maybe it is deviating a bit from Qt. It’s probably something I’m not doing correctly from the Qt paradigm perspective but this is one of those problems where I feeling lost. I’ve just had one of those rare deadlock and it happened like this: - This is a music making application. I have the audio processing and the GUI. - In the audio render thread, I call the processing of the sequencer which is responsible for handling the music events. - There are visual representations of this elements that contains the notes that are being played - During the processing of the musical steps, there is a signal that is being called. It got stuck there. But invoking a method as a queue connection in another thread shouldn’t be a problem, right? QMetaObject::invokeMethod(this, &DSClip::stepChanged, Qt::QueuedConnection); This invoke will trigger a signal that will request the DSClip visual instance to be updated on the QML side. Here is the place it got stuck in the audio render thread. It got locked when invoking the method. Does this ring any bell? Thanks! Best, Nuno
> On 19 Jul 2024, at 12:00, Dennis Luehring <dl.so...@gmx.net> wrote: > > Am 19.07.2024 um 12:52 schrieb Nuno Santos: >> Can data race cause deadlocks? >> >> Or should I explicitly look for deadlock: "lock-order-inversion (potential >> deadlock)” > > > data races can maybe get you into deadlocks someway... but you should > look for lock-order-inversions and fix them (even if very hard to > sometimes understand why they happening) > > > btw: the discussion is drifting away from Qt itself :)
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
