On Monday, 18 May 2020 21:12:55 PDT David M. Cotter wrote: > i thought your objection was that objects derived from QObject, if they are > used on a back thread then they must be either allocated there or "moved" > there.
Correct. > but since this i_auP is NOT a QObject, it's my own class, that i'm fine to > allocate it in one thread (main) and then use it on another thread (audio > pump thread) (provided and assuming i am careful to mutex any access from > the main thread) i_auP is not a QObject, but i_auP->i_qGeneratorP is. How was *that* pointer obtained? > > Are you saying that this calls a function that returned null? > > sorry, what is "this" and what function are you referring to that returns > null? The code I had pasted: i_auP(in_thiz->GetCUnit_Out()) Since you initialise i_auP using the same function (GetCUnit_Out) that later you initialise auP in render() and then use auP->i_qGeneratorP, I have to ask if at this time the generator pointer is already valid. And one more time: show the rest of the code. I'm not going to keep asking what the functions you called do if they are not shown. I want to see the lines that create ALL QObjects used in the thread. > > I repeat my request for a compileable example. > > i hear you loud and clear but let's assume that's not happening for now and > see how far we get That's easy: we're getting only this far. This is the last email until you show compileable code. There's a good chance the bug is not in the code you pasted. I don't need to see your application. I need you to reduce it to a self- contained, compileable example. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest