Gibt es unten eine Racebedingung?

Question

Ich habe den Code in meinem Express-Server unten (habe es der Kürze wegen gekürzt). Ich habe ein gemeinsames Objekt, das ich in drei verschiedenen ruhigen Endpunkten hinzufüge/modifiziere/lese. Da alle HTTP-Anfragen in Nodejs asynchron sind, konnte ich beide Requests zur gleichen Zeit setzen und bekommen. Obwohl PUT passiert ist, aber sagen wir, dass der Status nicht aktualisiert ist, könnte mein GET eine etwas schale Antwort bekommen?

Von dem, was ich verstehe, und meine Tests zeigen, dass es hier keine Race Condition gibt. Da das Aktualisieren des Objekts results eine synchrone Operation ist und alle asynchronen Operationen darauf warten sollten. Kann jemand mit einer besseren Erklärung helfen, ob das richtig ist oder nicht?

var obj = {}; 
    const exec = require('child_process').exec; 
    app.post('/foo', (req, res) => { 
     var result = {}; 
     result.id = generateSomeRandomId(); 
     result.failed = 0; 
     result.status = 'running' 
     //execute some command and update result 
     const child = exec('some command'); 
     child.stdout.on('data', (data) => { 
      //some logic 
     }); 
     child.stderr.on('data', (data) => { 
      result.failed = result.failed + 1; 
      }); 
     child.on('close', (code, signal) => { 
       if (signal !== null && signal !== undefined) { 
        result.status = 'cancelled'; 
       } else { 
        result.status = 'completed'; 
        result.runtime = calculateRunTime(); 
       } 
     }); 
     result.pid = child.pid; 
     obj[result.id] = result; 
     res.send(result); 
    } 

    app.put('/foo/:id', (req, res) => { 
     var result = obj[req.params.id]; 
     if (result.status === 'running' && result.pid !== undefined) { 
       kill(result.pid, 'SIGKILL'); 
       result.status = 'cancelled'; 
       result.runtime = calculateRunTime(); 
     } 
     res.send(result); 
    } 
    app.get('/foo/:id', (req, res) => { 
     var result = obj[req.params.id]; 
     res.send(result); 
    } 

Answer 1

Sie haben nichts, was ich eine "Race Condition" nennen würde; Hier ist ein Element der Unsicherheit im Spiel, aber in der Praxis wird es wahrscheinlich keine Rolle spielen.

Es sieht aus wie Ihre post startet einen Prozess und gibt die ID, Ihre put bricht den Prozess ab, und Ihre get gibt den aktuellen Status des Prozesses zurück. Von diesem versichere ich, dass Sie nie in der Lage sein werden, get bis Ihre post abgeschlossen ist und die ID bereitstellt.

Wenn Sie einen get Anruf tätigen, der empfangen und zurückgegeben wird, bevor Ihre asynchronen exec Listener abgeschlossen sind, erhalten Sie den letzten in Bearbeitung befindlichen Status - ich nehme an, dass das von Entwurf ist. Der einzige mögliche Konflikt hier ist, wenn Sie einen put Aufruf gemacht haben, um Ihren Prozess anzuhalten.

Sowohl Ihre put als auch Ihre get sind synchron, wenn es um die Interaktion mit Ihrem Ergebnisobjekt geht. Daher wird diejenige, die zuerst empfangen wird, diejenige, die zuerst abgeschlossen wird. Sie können die Anforderung zur Prozesslöschung für unsere Zwecke ignorieren, da das Ergebnisobjekt nicht geändert wird. Es gibt keine Garantie, dass sie in der gleichen Reihenfolge empfangen werden, in der sie vom Kunden gesendet wurden, was in Ihrem Szenario möglicherweise von praktischer Bedeutung ist.

ich glaube (obwohl mein Gedächtnis hier fehlerhaft sein kann), dass, wenn Sie cluster verwendet haben Anfragen in verschiedenen Prozessen zu behandeln, würden Sie nicht in der Lage sein, Daten zu übergeben um über ein gemeinsames Objekt trotzdem, so dass jede Komplexität hinzugefügt durch diese Möglichkeit ist bereits ausgeschlossen.

Daher sind Abweichungen in der Netzwerkleistung und Zuverlässigkeit Ihre einzigen echten Wildcard hier. Der Server verarbeitet Anfragen in der Reihenfolge, in der sie eingehen, und gibt Ihnen die erwarteten Ergebnisse. Wenn Sie nur einen einzigen Client haben, können Sie warten, bis Sie die Antwort von Ihrer vorherigen Anfrage bekommen, um die nächste zu senden, was möglicherweise Ihre Leistung inakzeptabel verlangsamen, aber mehr oder weniger kugelsicher machen würde. Ansonsten senden Sie einfach Ihre Anfragen und machen Sie sich keine Sorgen, machen Sie Ihre App robust genug, um & eine zweite Stornierungsanfrage zu bearbeiten, auch wenn Sie den Vorgang bereits abgebrochen haben.

Answer 2

Es ist nur eine Idee, aber vielleicht ein Versprechen hier hilfreich sein könnte:

var obj = {}; 
const exec = require('child_process').exec; 
app.post('/foo', (req, res) => { 
    var result = {}; 
    result.id = generateSomeRandomId(); 
    result.status = 'running'; 
    const child = exec('some command'); 
    child.stdout.on('data', (data) => { 
     //some logic 
    }); 

    result.promise = new Promise(resolve => { 
     child.stderr.on('data', (data) => { 
      result.failed = result.failed + 1; 
      resolve(false); 
     }); 
     child.on('close', (code, signal) => { 
      // ... 
      resolve(true); 
     }); 
    }); 

    result.pid = child.pid; 
    obj[result.id] = result; 
    res.send(result); 
} 

app.get('/foo/:id', (req, res) => { 
    var result = obj[req.params.id]; 
    if(result.status === 'running') { 
     result.promise.then(() => res.send(result)); 
    } 
    else { 
     res.send(result); 
    } 
} 

In diesem Fall GET nur reagieren würde, wenn die child durch Fehler gemacht wird oder ‚Schließen‘ Ereignis.