QT QThread mit QTimer und QSerial - Parenting

Question

Ich versuche, ein "in sich geschlossenes" Kommunikationsobjekt in einem anderen Thread zuzuordnen, um es von der GUI-Verarbeitungsverzögerung isoliert zu halten.

Also, in einem "AppCore" Objekterstellung erstelle ich ein "CommCore" ohne Eltern:

cAppCore::cAppCore(QObject *parent) : QObject(parent) 
{ 
    .... 
    CommCore = new cCommCore; 
    (here I do signal-slot connections between CommCore and AppCore) 
    .... 
} 

und im CommCore Konstruktor ich folgendes tun:

cCommCore::cCommCore(QObject *parent) : QObject(parent) 
{ 
    CommThread = new QThread(this); 
    CommSerial = new QSerialPort(this); 
    CommTimer = new QTimer(this); 

    connect(CommSerial,&QSerialPort::readyRead,this,&cCommCore::ProcessRXByte); 
    connect(CommSerial, static_cast<void (QSerialPort::*)(QSerialPort::SerialPortError)>(&QSerialPort::error), this, &cCommCore::HandleSerialError); 
    connect(CommTimer, &QTimer::timeout, this,&cCommCore::TimerTimeout); 

    CommTimer->start(OFFLINE_POLL_TIME); 
    this->moveToThread(CommThread); 
    CommThread->start(QThread::HighPriority); 
} 

meine Fragen nun:

1- Es ist in Ordnung, das Thread-Handler-Objekt zum Kind des verschobenen Objekts zu machen? wie es im GUI-Thread erstellt wird (wo der Konstruktor aufgerufen wird) und dann in den Thread verschoben wird, der von ihm selbst behandelt wird (wenn ich eine Kontrolle darüber benötige, werde ich es innerhalb des CommCore-Objekts behandeln)

2- Es ist in Ordnung, den Timer im Konstruktor zu starten (was im selben Thread des Timer-Konstruktors, GUI-Thread) ist, und gleich danach alles in den neuen Thread zu verschieben?

3- Wenn ich den Timer später starten wollte, würde der einzige Weg durch Signal-Slot sein? wo ein Signal im GUI-Thread emittiert und mit einem CommCore-Slot verbunden ist (der dann in den CommCore-Thread eingereiht und ausgeführt wird)

4- In Anbetracht dessen, dass alle meine Interaktionen zwischen meinem CommCore-Objekt und dem AppCore (GUI-Thread) sind durch Signal-Slot gemacht (was threadsicher ist), ist es konzeptionell korrekt? (Die Idee des Objekts bewegen sich selbst und seine Kinder zu einem neuen Thread, etc.)

5- Meine serielle Kommunikation Routinen basierend auf Pooling (zeitlich durch den Timer) wird von der GUI Verarbeitung Verzögerungen abgeschirmt werden? (Ich meine, es wird keine Verzögerungen bei der Erzeugung und Verarbeitung von Ereignissen geben, die von den Serial- und Timer-Objekten erzeugt werden.)

danke!

Answer 1

this->moveToThread(CommThread); 

wird gelingen, wenn das Objekt kein Elternteil hat. Sie müssen also die Signatur Ihres Konstruktors ändern. Abgesehen davon ist es in Ordnung, da das Objekt mit seinen Kindern bewegt wird ...

Der Timer sollte nicht so gestartet werden, da er in einen anderen Thread verschoben wird. Sie sollten InvokeMethod so verwenden, dass es die richtigen Thread ist, die den Betrieb

QMetaObject::invokeMethod(CommTimer, "start"); 

Für weitere Fragen alle Antworten sind ja perfoms. Solange Sie Signale verwenden und mit invokeMethod aufrufen, ist es so, als würde der Thread aus einem runnable-Pool abgerufen und ausgeführt.

So Thread sicher und unberührt von den Haupt-Thread-Unterbrechungen.