Process.exitValue () und Process.destroy () Features

8

Ich habe mit Process und ProcessBuilder experimentiert und komme mit diesem SSCCE.

%Vor%
  1. Wenn ich diesen Code ausführe und den Editor vor dem Timeout von 10s schließe. Der Aufruf von destroy() zeigt beim Versuch, den bereits beendeten Prozess zu stoppen, kein Problem an. Warum?
  2. Wenn Sie diesen Code ausführen und den Editor überhaupt nicht schließen (mit kommentiertem zweiten Schlaf)

Es scheint, dass zerstören ist asynchroner Aufruf ( nur ein Signal senden? ), was zu einer Ausnahme in zweiten exitValue()

%Vor%
  1. Wenn ich diesen Code ausführe und den Editor überhaupt nicht schließe (mit unkommentiertem zweitem Schlaf), dann wirft der zweite exitValue niemals Exception, obwohl der Sleep-Wert nur 1 ms beträgt. Liegt das an sleep() overhead selbst? Zweite exitValue würde 1. zurückgeben.

PS. Ich starte es von Windows 7 und Eclipse.

    
Nikolay Kuznetsov 20.12.2012, 12:39
quelle

3 Antworten

1
  1. Warum würde es ein Problem zeigen? Sie versuchen, einen bereits zerstörten Prozess zu zerstören. Die Angabe von Process.destroy() sagt nicht, was passiert, wenn es nichts zu zerstören gibt, also ist es logisch (ich nehme an) anzunehmen, dass es nichts zu beanstanden gibt, wenn es nichts zu zerstören gibt. Vergleichen Sie mit Thread.join() , das nicht nur stirbt, wenn der Thread bereits beendet ist.

  2. Die einzige Möglichkeit, einen Prozess zu beenden, ist ein Signal zu senden. Auf einigen Betriebssystemen gibt es andere, "gewaltsamere" Arten (auf einigen Plattformen ist es beispielsweise möglich, den Prozess einfach aus der Liste der laufenden Prozesse des Betriebssystems zu entfernen. Die Ergebnisse sind nicht definiert und enden normalerweise hässlich), aber zumindest mit Plattformen, die ich kenne, geht es wirklich um das Senden von Signalen.

  3. Dies ist in der Tat möglich, weil es Zeit braucht, um Thread.sleep() aufzurufen. Versuchen Sie, den Zeitüberschreitungswert zu erhöhen.

Isaac 20.12.2012, 13:17
quelle
1

Ich erwarte, dass die Methode destroy () die native Windows-Funktion TerminateProcess aufruft. Bei MSDN habe ich folgendes gefunden:

  

TerminateProcess ist asynchron; es leitet die Kündigung ein und kehrt sofort zurück. Wenn Sie sicherstellen müssen, dass der Prozess beendet wurde, rufen Sie die WaitForSingleObject-Funktion mit einem Handle für den Prozess auf.

Also ich denke, es erklärt, dass Zerstörung in der Tat asynchron ist.

Ein weiterer Auszug aus derselben Quelle:

  

Die Funktion TerminateProcess wird verwendet, um einen Prozess bedingungslos zu beenden.

Ich denke, dass "bedingungslos" erklären kann, warum der Aufruf von destroy () bei einem Beendigungsprozess nicht fehlschlägt.

Hoffe diese Hilfe. (wirklich interessante Frage!)

    
ben75 20.12.2012 13:17
quelle
1

ProcessImpl.java on destroy Methodenaufruf native Funktion terminateProcess :

%Vor%

terminateProcess ist plattformabhängig und für Windows können Sie Quellen finden hier . Es ist nur Windows TerminateProcess Funktion aufrufen (Link zu dieser Funktion war in der Antwort oder Sie können es googlen) mit uExitCode=1 - das ist, warum der Code des zerstörten Prozesses 1 ist.

In Linux wird so ähnlich wie dies . Und als Beweis nächsten Code geben 143 in Ubuntu, die SIGTERM ( Ссылка ) entsprechen:

%Vor%     
knok16 18.02.2015 19:07
quelle