boost dataflow_exception, wenn von Programm

Question

gegellt

Ich portierte kürzlich eine Qt-App, um QTcpSockets anstelle der Posix direkt zu verwenden. Der Renderer, den ich verwende, verfügt über Code, um die Ansichtsanwendung durch Forking zu starten, wenn sie nicht bereits ausgeführt wird. Mit meiner neu refactored App scheint es gut zu funktionieren, wenn die App gestartet wird, bevor ich meinen Renderer starte. Wenn ich jedoch den Renderer starte, ohne dass die Ansicht-App bereits ausgeführt wird, wird der Fork-Code aufgerufen, und das Programm stürzt in der Regel in der Hälfte der Zeit ab.

Qt has caught an exception thrown from an event handler. Throwing 
exceptions from an event handler is not supported in Qt. You must 
reimplement QApplication::notify() and catch all exceptions there. 

terminate called after throwing an instance of ' 
boost::archive::iterators::dataflow_exception' 
    what(): attempt to decode a value not in base64 char set 

Da diese Ausnahme nur ausgelöst wird, wenn die Gabel() -Methode verwendet wird, frage ich mich, ob es etwas in der Refactoring ist? Ich glaube auch, dass es nur passiert, wenn der Renderer (der die Viewer-App startet) von innen durch die Qt-App ausgeführt wird. Wenn die Ansichtsanwendung direkt vom Renderer gespalten wird, wird dieses Problem nicht angezeigt. Ich bin nicht sicher, was die fork() tun könnte, die diese Ausnahme verursachen könnte.

int pid = fork(); 
if (pid != -1) 
{ 
    if (!pid) 
    { 
     // Child process executes the following after forking. 
    char arg1[] = "piqsl"; 
    char arg2[] = "-i"; 
    char arg3[] = "127.0.0.1"; 
    char* argv[4] = {arg1, arg2, arg3, NULL}; 
    // TODO: need to pass verbosity level for logginng 
    signal(SIGHUP, SIG_IGN); 
    nice(2); 
    execvp("piqsl",argv); 
... 

Der einzige Unterschied in dem Refactoring-Viewer-App ist es QTcpSockets (und ein QTcpServer) und jetzt verbindet gegen libQNetwork verwendet. Stört diese Bibliothek jetzt vielleicht die Verstärkung?

Answer 1

Das Problem ist, dass fork() eine exakte Kopie des ursprünglichen Prozesses einschließlich aller offenen Dateihandles erstellt. Qt scheint einige Pipes/Sockets für die interne Kommunikation zu verwenden und da dies die gleichen Pipes/Sockets im gegabelten Prozess sind, stehen sie im Konflikt mit dem ursprünglichen Prozess.

Sie werden wahrscheinlich mehr Glück mit exec() haben - meines Wissens gibt es keine Möglichkeit, die QApplication nach dem Forking sicher zu instanziieren. Alternativ sollte es funktionieren, wenn Sie vor die QApplication erstellen.