Wozu sind Jobs eigentlich gut?

[Der schöne Günther]

Ich möchte in meiner aus Plugins bestehendden Anwendung weg von DLLs die in den laufenden Prozess (Thread?) eingeklinkt werden, hin zu einer Multi-Prozess-Architektur ähnlich beispielsweise dem Internet Explorer oder Google Chrome.

Als erstes bin ich über Jobs gestoplert. MSDN spricht hierzu:

Zitat:

A job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on a job object affect all processes associated with the job object. Examples include enforcing limits such as working set size and process priority or terminating all processes associated with a job.

Da ich momentan arge Probleme in der Umsetzung habe (das gleiche Problem wie dieser Herr), frage ich mich, was mir das konkret eigentlich bringt. Ich habe das Gefühl, dass mir so etwas nur auf großen Serveranwendungen, wenn ich die Lasten auf einem Multiprozessorsystem besser verteilen will, wirklich etwas bringt.

Die einzigen Komfortfunktionen die ich spontan sehe sind

• Herausfinden, welche Prozesse momentan im Job stecken
• Mit einem Befehl den gesamten Job terminieren

Die einzigen zwei Themen zu Windows-Jobs die ich hier im Forum gefunden habe sind:

• http://www.delphipraxis.net/71699-jo...-auslesen.html
• http://www.delphipraxis.net/123756-e...x-starten.html

Habe ich etwas übersehen?

[p80286]

Vor Urzeiten habe ich mit den "big Irons" gespielt und da gab es die sog. JCL (JobControlLanguage).
Da wurden mehrere Programme in einem Job zusammen gefaßt, ähnlich wie in einer Batch-Datei, mit dem Unterschied, wurde der Job abgebrochen gab es keine, auch keine Teilergebnisse. Und ganz besonders wichtig, man konnte über Jobklassen (entspricht der Priorität unter Windows) die Ausführung (sgeschwindigkeit) beeinflussen.

Gruß
K-H

[Der schöne Günther]

Ja, das scheint allgemein die Hauptmotivation für Jobs zu sein - Die Verteilung über mehrere Prozessoren, Größe des Working Set und ähnliches steuern.

Einen weiteren Vorteil, der genau auf meine Zwecke passt, hat es weiterhin: Packt mein Hauptprogramm neue Prozesse in den entsprechend eingestellten Job, endet aber später auf x-beliebige Weise, kümmert sich Windows um das Beenden aller Prozesse, die noch im Job stecken. Das ist eigentlich eine tolle Sache.

Weiterhin kann man sich über bestimmte Ereignisse, wie das Beenden eines Prozesses oder das Überschreiten einer bestimmten Systemauslastung informieren lassen.

Interessant ist auch, dass sich die Sache mit Windows 8/Server 2012 nochmal stark ändert, ab da können Prozesse sogar in mehreren Jobs gleichzeitig stecken. Dafür sehe ich spontan aber weder Verwendung noch Sinn

Mein ursprüngliches Problem habe ich auch gelöst, ich hatte nicht gemerkt, dass Anwendungen, die über den Windows Explorer gestartet werden, schon direkt in einen Job gepackt werden. Startet man die Anwendung über die Eingabeaufforderung, passiert das ulkigerweise nicht!

[p80286]

Zitat von Der schöne Günther:

Mein ursprüngliches Problem habe ich auch gelöst, ich hatte nicht gemerkt, dass Anwendungen, die über den Windows Explorer gestartet werden, schon direkt in einen Job gepackt werden. Startet man die Anwendung über die Eingabeaufforderung, passiert das ulkigerweise nicht!

Kannst du das mal näher erklären?
Nach meinem Verständnis sind die Windows(Dialog)Programme eigentlich nicht "Job-tauglich", aber das könnte auch an der unterschiedlichen Interpretation der gleichen Vokabel liegen.

Gruß
K-H

[Der schöne Günther]

Ich bin eben auch gerade über etwas im Bereich Windows PowerShell gestolpert, auf den ersten Blick schien da auch etwas Job genannt zu werden, was eventuell jetzt nicht das ist, was in der Windows-API eigentlich als Job bezeichnet wird. Ich habe allerdings nicht genau hingesehen und finde die Seite auf die Schnelle nicht mehr ...

MSDN erklärt es letztendlich doch sehr gut:

Auf About Processes and Threads steht: A job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on the job object affect all processes associated with the job object.

Auf der Seite Job Objects steht eine gute Zusammenfassung, was man damit typischerweise anstellen kann.


Mein ursprüngliches Problem war exakt das, wie es bei StackOverflow schon einmal aufgetaucht ist: Starte ich meine Delphi-Anwendung von der cmd.exe aus (oder z.B. start.exe), steckt die Anwendung in keinem Job.
So kann ich einen neuen Job mit den wildesten Eigenschaften erstellen und mich selbst dann dort hineinpacken!

Starte ich mein Programm normal im Explorer per Doppelklick auf die Exe oder Verknüpfung, stecke ich bereits in einem Job. Das kann man einfach direkt mittels IsProcessInJob herausfinden. Lustigerweise kann man mittels QueryInformationJobObject zwar Informationen über den Job, in welchem man auf alle Zeit gefangen ist auslesen, sie aber nicht modifizieren: Man kennt weder den Namen noch das Handle des Jobs. Das ist so gewollt und wahrscheinlich auch gut so.

Trotzdem hindert mich jetzt immer noch keiner daran, einen neuen Job zu erstellen und mittels dem dwCreationFlags -Parameter bei CreateProcess noch ein CREATE_BREAKAWAY_FROM_JOB (0x1000000) anzugeben, denn ein mit CreateProcess erstellter Job landet sonst normalerweise im selben Job wie sein Parent-Prozess.


PS: Den Großteil der nötigen Funktions-Deklarationen und Konstanten für Delphi liefert schwa226 netterweise schon hier

[p80286]

Ich habe gerade einmal hier herein geschaut. Das sieht so aus, als würde die klassische Batch-Job-Verarbeitung wieder auferstehen.
Fazinierender Gedanke,
alles schon mal dagewesen.
Aber wohl eher für Server als für Desktop-PCs geeignet, sieht man mal von Virenscannern und ähnlichen Hintergrundaktivitäten ab.

Gruß
K-H

[Der schöne Günther]

Ja, da lässt sich eine Menge abfragen.

Interessant auch, dass es erst mit SP3 für WinXP zögerlich kam und mit Windows 8 nochmal kräftig erweitert wird (verschachtelte Jobs).

Ich werde es definitiv verwenden, allein aus dem Grund, dass alle Kindprozesse geschlossen werden, egal was mit meiner Hauptanwendung passiert. Somit muss ich mir keine Sorgen machen, dass irgendwelche Dinge unsichtbar im Hintergrund noch Dateien, serielle Ports, shared Memory oder sonstwas offen halten.