Kommunikation von Signalhaendlern zum "regulaeren" Teil geht nur ueber Globale ressourcen (variablen)
weiterhin solltes beachten, das dein signalhaendler nicht ewig zeit verbraten sollte, einige os reagieren da ned gut drauf
als gloabes Object hasst du im Qt universum schon die QAplllication instanz (qApp)
Die kannst doch nutzen dafuer ....
Im signalhaendler holst dir die qApp (includes)
und schickst(postevent) einfach ein Userdefiniertes Signal ... an, die QApp selber.
in deiner QApp (hasst du schon eine eigene Ableitung von QApplication ? ) faengst das signal (event ueberladen) ab und reagierst entsprechend drauf.
Alternativ, wenn du QApplication nicht ueberladen willst, kannst du auch nen eventhaendler installieren, der das ereigniss abfängt.
Das wichtige ist, das im Handler nur das Event in die Queue gespult wird. Abgearbeitet wird das event dann im normalen context ....
Nur ne Frage am Rande und aus eigenem Interesse:
ich habe einige zeitaufwändige Funktionen, in meiner Anwendung, in einen seperaten Prozess ausgelagert.
Warum multiprozessing und nicht multithreading ?
Ist ein Prozess mit seiner Aufgabe fertig so sendet er das Signal SIGUSR1 an die Hauptanwendung
Signale als IPC sind doch sehr aehm eingeschränkt in ihrem funktionsumfang
Dafür aber sehr low level
Warum kein hoeheres level bei der IPC, z.b. Pipes ? Stdin/stdout umleitung funzt mit qt auch super
Ist ein Prozess mit seiner Aufgabe fertig so sendet er das Signal SIGUSR1 an die Hauptanwendung
Warum eigentlich ? der prozess endet doch dann ? oder laesst den weiterlaufen ? mit was ?
Wenn der Kind prozess sich beendet ... sendet er sowieso SIGCHLD an das elternprogram ... warum dann noch nen SIGUSR1 ?
viele bibliotheken bieten assynchrone controlle von prozessen an .... so zum beispiel auch die QT
schau dir mal QProcess an ...
Da kannst nen (fremd) prozess auch schoen "nebenlaufig" starten (wie system) .... und wenn der sich beendet wird dir das schoen auf nen Qt-Signal gemappt, sogar mit Fehlercode.
Einfacher gehts bald nicht.
Ciao ...