C# Prüfe ob Prozess läuft

[vilden]

Hey ho =)

Ich versuche mich gerade an einem "läuft der Prozess" Programm.
Bisher folgendes:

public bool CheckIfAProcessIsRunning(string processname)
        {
            return Process.GetProcessesByName(processname).Length > 0;
        }

   private void button1_Click(object sender, EventArgs e)
        {
            bool fire_running = CheckIfAProcessIsRunning("firefox");

            if (fire_running == true)
            {
                MessageBox.Show("Firefox läuft.");
            }
            else
            {
                MessageBox.Show("Firefox läuft nicht mehr");
            }
 }

Soweit funktioniert das auch, jedoch erfolgt die Prüfung logischerweise nur wenn ich auf den Button klicke. Nun wollte ich aber das der Prozess dauerhaft geprüft wird, jedoch komm ich nicht ganz weiter.

while (fire_running == true)
            { 
                fire_running = CheckIfAProcessIsRunning("Firefox");
                if (fire_running == false)
                {
                    //mache irgendetwas
                }
            }

Hoffe ihr könnt mir da helfen =)

 

[Madman1209]

Hi,

ohne dir alles vorzukauen: Das Stichwort heißt "Timer" Damit kannst du zyklisch (z.B. alle 5 Sekunden) deine Prüfung ausführen.

Ist das so gemeint gewesen?

VG,
Mad

 

[Gurke95]

Hi ich würde eher sagen das Stichwort heißt Event.. in in der Eventmethode hinterlegst du die Abfrage des Processes. Du solltest dich also mit Delegates und Events beschäftigen, ein Event kann beispielsweise durch eine Änderung eines Wertes ausgelöst werden..

Ergänzung (27. Januar 2012)

Natürlich kannst du das Event auch durch einen timer auslösen lassen.

 

[bepi74]

Wenn du dich für den Timer entscheidest und das ganze in deinem Windows-Forms Programm laufen lässt, dann entscheide dich für den "System.Windows.Forms.Timer" und nicht den "System.Threading.Timer". Das kann dir eine Menge Ärger ersparen, da der Programmcode dann im GUI-Thread ausgeführt wird.

 

[vilden]

Danke! Habe es jetzt erst einmal mit Timer gelöst
Als nächstes werde ich mich mit Delegates beschäftigen.

€: @bepi: Habe System.Windows.Forms.Timer benutzt

 

[holy]

Das kann dir eine Menge Ärger ersparen, da der Programmcode dann im GUI-Thread ausgeführt wird.

[IRONIE]Vollkommen richtig. Denn genau dazu ist der GUI-Thread da. Massig Aufgaben reinpumpen, die über nichts mit der GUI zu tun haben. [/IRONIE]

 

[schlzber]

[IRONIE]Vollkommen richtig. Denn genau dazu ist der GUI-Thread da. Massig Aufgaben reinpumpen, die über nichts mit der GUI zu tun haben. [/IRONIE]

Undifferenzierter Unsinn.

Im Kontext dieses Threads.

 

[Madman1209]

Hi,

da muss ich holy recht geben: rechenintensive Sachen gehören in einen eigenen Thread ausgelagert - zumal das .NET-Framework doch gerade für den Einstieg die "Background-Worker" zur Verfügung stellt, wo man sich um fast nichts mehr kümmern muss...

VG,
Mad

 

[schlzber]

Hi,

da muss ich holy recht geben: rechenintensive Sachen gehören in einen eigenen Thread ausgelagert - zumal das .NET-Framework doch gerade für den Einstieg die "Background-Worker" zur Verfügung stellt, wo man sich um fast nichts mehr kümmern muss...

VG,
Mad

Es geht darum zu prüfen, ob ein bestimmter Prozess läuft. Das klingt nicht nach "rechenintensiver Sache". Multithreading macht es in diesem Fall nur unnütz komplex und kompliziert.

 

[holy]

Undifferenzierter Unsinn.

Selten so einen Quatsch gelesen.
Zu prüfen, ob ein Prozess läuft oder nicht, hat nichts mit dem GUI Thread zu tun. Es ist auch egal, ob Forms oder WPF. Auf dem GUI Thread haben nicht GUI-Aufgaben nichts zu suchen.
Wenn man Probleme kriegt, weil ein anderer Thread versucht die GUI zu ändern, und das ist der eigentliche Gedanke über den Tip mit dem GUI Thread, dann macht man grundlegend etwas falsch.
Wem InvokeRequired in Verbindung mit Invoke oder BeginInvoke zu kompliziert ist, der kann mit Forms auch den Dispatcher benutzen. My 2 cents.

 

[Madman1209]

Hi,

klar, grundsätzlich ist das nicht rechenaufwändig, in diesem einen Fall. Aber ich sehe das genauso wie holy, man sollte da von Anfang an auf strikte Trennung zwischen "Darstellung" und "restlicher Logik" achten. Wenn man sich diesen Stil angewöhnt hat man "im späteren Leben" einfach weniger Probleme. Und wenn wirklich die Invokes und der Einstieg in MultiThreading zu komplex sind: die Background-Worker sowas von einfach verständlichund mit etlichen Beispielen im Internet vertreten... finde da gibt's keine Ausreden

VG,
Mad

 

[schlzber]

Nach dieser Logik müsste mach auch auf Klick auf den Button im EventHandler nen Thread starten, dessen Erstellung allein mindestens 10x soviel Aufwand im Betriebssystem erfordert als direkt die GetProcessByName-API aufzurufen.
Also du kannst gerne so programmieren, ich entscheide lieber anhand der konkreten Aufgabe, ob sie im GUI-Thread oder im Hintergrund erledigt wird.

 

[Madman1209]

Hi,

das Button-Klick-Event wird nunmal von der GUI respektive dem Button ausgelöst. Die Arbeit, die da drinnen ausgelöst wird sollte selbstverständlich in einem eigenen Thread laufen. Was ist daran so kompliziert? Wenn man es immer so löst ist es doch kein Mehraufwand. 10x soviel Aufwand? Ich bitte dich...

Lies mal eine 500 MB-XML-Datei ein und erstelle daraus eine Datenbank, direkt im GUI-Thread... da wird sich der Kunde freuen, wenn er nicht mal mehr das Programm beenden kann (ausser den Prozess zu killen) und "Keine Rückmeldung..." die Daueraussage ist.

Es geht darum: In diesem Fall ist es kein Beinbruch, aber die Empfehlung, GUI von Arbeit zu trennen, die kannst du einfach nicht abtun. Und wenn man sich so etwas gleich angewöhnt ist es auch nichts schlimmes. Die Vorteile überwiegen einfach klar.

VG,
Mad

 

[schlzber]

Hi,

klar, grundsätzlich ist das nicht rechenaufwändig, in diesem einen Fall. Aber ich sehe das genauso wie holy, man sollte da von Anfang an auf strikte Trennung zwischen "Darstellung" und "restlicher Logik" achten. Wenn man sich diesen Stil angewöhnt hat man "im späteren Leben" einfach weniger Probleme. Und wenn wirklich die Invokes und der Einstieg in MultiThreading zu komplex sind: die Background-Worker sowas von einfach verständlichund mit etlichen Beispielen im Internet vertreten... finde da gibt's keine Ausreden

VG,
Mad

Diese Trennung muss aber nicht zwangsläufig auf Thread-Ebene passieren, sie läßt sich auch auf Klassen-Ebene realisieren ohne dass es deswegen eine schlechtere Vorgehensweise wäre.

 

[Madman1209]

Hi,

Klassen haben damit absolut nichts zu tun. Wenn eine große Aufgabe in deinem ButtonKlick die GUI komplett einfriert kannst du das in zehn verschiedenen Klassen haben, das ändert nichts am Fehlverhalten!

Genug OT, der TE wird sich sein Bild schon machen. Die Mehrzahl der Beteiligten ist für eine mehrthreadige Architektur. Was er daraus macht bleibt ihm überlassen.

VG,
Mad

 

[schlzber]

Hi,

das Button-Klick-Event wird nunmal von der GUI respektive dem Button ausgelöst. Die Arbeit, die da drinnen ausgelöst wird sollte selbstverständlich in einem eigenen Thread laufen. Was ist daran so kompliziert? Wenn man es immer so löst ist es doch kein Mehraufwand. 10x soviel Aufwand? Ich bitte dich...

VG,
Mad

Bitte nochmal lesen, was ich genau geschrieben habe: "10x soviel Aufwand im Betriebssystem".
Was ist daran so kompliziert? Ein GetProcessByName-Aufruf ist nach weniger als einer Zehntel Millisekunde erledigt und ich habe das Ergebnis. Wenn ich das in einem Thread erledige dauert es ~1ms bis vom Betriebssystem der Thread erstellt wurde und jetzt kann erst MEIN Teil der Arbeit starten!.

Was ich sagen will ist dass so einfache Sachen wie hier beschrieben einfach keinen dedizierten Thread rechtfertigen. Wenn man dagegen eine Primfaktorenzerlegung o.ä. machen will, nimmt man natürlich einen BackgroundWorker oder selbstverwalteten Thread dafür. Das stelle ich doch gar nicht in Frage! Ich halte nur diese Pauschalisierung und striktes Beharren auf Trennung zwischen GUI-Thread und allem anderen für ziemlich unsinnig und unpraktikabel.

Guckt euch dochmal das neue async-Keyword für C# 5.0 an, dessen Hauptzweck es gerade ist, wieder mehr Sachen vom GUI-Thread erledigen zu lassen!

Ergänzung (27. Januar 2012)

Hi,

Klassen haben damit absolut nichts zu tun. Wenn eine große Aufgabe in deinem ButtonKlick die GUI komplett einfriert kannst du das in zehn verschiedenen Klassen haben, das ändert nichts am Fehlverhalten!

Dafür nimmt man dann einen Extrathread. Hast du bisher geschlafen?

Genug OT, der TE wird sich sein Bild schon machen. Die Mehrzahl der Beteiligten ist für eine mehrthreadige Architektur. Was er daraus macht bleibt ihm überlassen.

VG,
Mad

Was hat das Thema hier jetzt mit demokratischen Prinzipien zu tun? Es geht nicht um die Wahl eines Bürgermeisters sondern um ein konkretes technisches Problem!

 

[derlolomat]

Es geht hier doch um die regelmäßige Wiederholung dieser Überprüfung, insofern verstehe ich nicht, wieso man das Ganze in den GUI-Thread schieben möchte. Es sei denn das Timer-Control benutzt keinen eigenen Thread sondern wird mit Form.Update() hochgezählt.

 

[schlzber]

Wer will hier was IN den GUI-Thread verschieben?

Ich meinte nur, dass es IN DIESEM FALL (sehr kurze Funktion mit potentiell mehrsekündigem Abstand aufgerufen) nichts bringt, diese AUS dem GUI-Thread zu verschieben, wenn ein Timer genommen wird, der die Events sowieso schon im GUI-Thread liefert, nur aus dem Glauben heraus, dass der GUI-Thread irgendwie heilig und unantastbar sei.

Alle anderen Fälle (Thread-Timer, zeitintensivere Funktionen, sehr viel kürzeres Intervall, etc.) sind davon unberührt.