Prozess Befehle ausführen lassen

[joggel]

Guten Morgen ihr da,

ich komme mir langsam etwas unbehaglich vor, weil ich euch so oft hier etwas frage, und ich kaum etwas zurück gebe…sagt mir einfach Bescheid wenn eure Geduld erschöpft ist. Ich versuche natürlich mich auch hier im Forum einzubringen…

Zu meiner jetzigen Frage:
Ich hätte gerne einen Prozess, der ständig im Hintergrund läuft, natürlich selbst geschrieben.
Mir soll es jetzt möglich sein diesen Prozess von außen zu veranlassen irgendwelche Aufgaben zu erfüllen; z.B. ein Programm starten (EXE ausführen) oder Rechner runterfahren….oder was auch immer.

Ich hätte es gerne so, dass ich dazu eine zweite EXE aufrufe, ihr Parameter übergebe, und diese zweite EXE übergibt dann diese Parameter dem Prozess, der diese Parameter interpretiert und entsprechend darauf reagiert.
Ich habe aber keine Idee wie man dazu vorzugehen hat.
Wisst ihr etwas darüber? Könnt ihr mir Tipps geben?

(Es soll unter Windows laufen)

Gruß

[joggel]

Okay, ich habe gerade mal etwas gegoogelt (was ich vlt mal in zukunft vorher machen sollte^^) und etwas über Interprozesskommunikation gefunden.

Ich vermute jetzt mal ganz naiv, dass es evtl durch WindowsMessages zu realisieren ginge?
Der Prozess soll aber kein Fenster haben....

[Krishty]

Pipes!

Verbinde die beiden Prozesse durch eine Pipe. Der ausführende Prozess liest von der Pipe, wird also erst aktiv, wenn ein Befehl ankommt. Der befehlende Prozess horcht auf Bestätigung, die erst kommt, wenn der ausführende Prozess fertig ist. Du brauchst kein Fenster, keinen Shared Memory, und kannst beliebige Daten übergeben (so lange sie keine Zeiger enthalten).

[joggel]

Vielen vielen dank.
Dieses Pipes sehen nützlich aus!!

[Krishty]

ich komme mir langsam etwas unbehaglich vor, weil ich euch so oft hier etwas frage, und ich kaum etwas zurück gebe…sagt mir einfach Bescheid wenn eure Geduld erschöpft ist. Ich versuche natürlich mich auch hier im Forum einzubringen…

Nee; ich bin froh, dass du fragst. Du kannst dir sicher sein, dass hier bei jeder Frage, die du stellst, zehn Leute mitlesen, die das auch wissen wollen, sich aber nicht getraut haben, zu fragen.

Wann immer das Thema aufkam, warum auf ZFX heute so wenig los ist, war die häufigste Antwort: Das sind alles so spezielle Spezialexperten, denen sind meine Fragen viel zu doof, darum stelle ich sie lieber wo anders. Das wollen wir so nicht und ich bin froh, wenn hier endlich mal Leben reinkommt.

[dot]

Von Pipes abgesehen könnte man auch Sockets verwenden. Vorteil davon ist, dass das relativ portabel ist und das Benachrichtigen dann auch über's Netzwerk funktionieren würde.

[joggel]

An Sockets habe ich auch gedacht...aber Pipes sind cooler^^

@Fragen stellen
Naja...ich hab nur n schlechtes gewissen, oder gehabt, weil ich immer frage aber kaum was zurücktebe. Kommt mir so vor als ob ich ausnehme; zumal es ja keine spielesprogrammierer Fragen sind...

[sfxon]

Ich würde für so etwas einen vielleicht stabileren Umweg geben.

-Einen Workerprozess der regelmäßig Befehle ausführen muss, kann man ganz easy mit Cronjobs (Linux, zB. crontab | Windows: Aufgabenplanung) triggern.
Damit muss man kein Programm im Hintergrund laufen lassen- sondern kann es ganz nach Bedarf in Intervallen abrufen. Vielleicht genügt das ja schon?

Die Prozesssteuerung würde ich dann über eine Datenbank laufen lassen. Damit kann man auch gleich schön debuggen/monitoren, ob die Prozesse durchgeführt wurden, und im Fehlerfall erneut ausführen/Mails senden/etc.. Der eine Prozess schreibt dazu einen Eintrag in eine Datenbank, und der andere liest sie aus. Das wäre auch mit Dateien möglich, allerdings muss man dann evtl. mit Lock Handles arbeiten - also die Dateien während des Schreibvorganges vor dem Auslesen schützen, damit man nicht an einen Punkt kommt, in dem gleichzeitig auf die Datei zugegriffen wird. Bei vielfältigen Aufgaben wird das aber schnell unübersichtlich - eine Datenbank ist also sicher besser geeignet.

Nun ist zu beachten, dass ich eher aus der asynchron arbeitenden Welt des WWW komme, von der oft behauptet wird, das da keine richtigen Programmierer sitzen. :)
Vor Websockets war da synchron auch noch nicht viel möglich. Die Möglichkeiten sind vielfältig. Ich finde diese hier mit am einfachsten, weil man nicht darauf angewiesen ist, dass beide Programme sofort reibungslos funktionieren -sondern man kann sich darauf konzentrieren, erst das Eintragen in der Datenbank richtig hinzubekommen - und dann das zweite Programm schreiben, welches die Einträge abarbeitet. :)

[antisteo]

Von all den vorgeschlagenen Sachen sind Pipes zwar nicht schlecht, aber Sockets (z.B. TCP auf localhost) sind nach meiner Erfahrung nach deutlich robuster.

Ansonsten wurde der Enterprise Bus noch gar nicht ins Spiel gebracht.

Wenn du eine ultra-portable Variante willst, die auch noch skaliert, kannst du auch eine SQL-Datenbank zur Parameterübergabe nutzen. Achte aber darauf, dass du per Transaktionen das Auslesen und Löschen der Tasks atomar machst.

[sfxon]

Enterprise Bus ist auch eine schöne Lösung. Wobei dann direkt Interfaces in Form von APIs oder ähnlichem erstellt werden müssen.
Mein Ansatz ist in gewisser Weise ein vereinfachter, bzw. ganz einfacher ESB.

[joggel]

@sfx
Uff...viel input für mich. Ich bin mit der ganzen sache nicht richtig vertraut.
ABER: Du hast geschrieben, wenn das Programm/Prozess regelmäßig auf ereignisse reagieren soll....
Das ding ist nur, das es eben nicht regelmäßig ist....sondern ganz unterschiedlich.
Ich habe es jetzt so gemacht, das ich das Lauschen an den Pipes in einen extre Thread ausgelagert habe, damit das ganze Programm/Prozess nicht zum erliegen kommt. Und so funktioniert es recht gut.

Aber ich will euch nicht aufhalten hier weitere Ideen reinzuhauen....ich kan nur lernen ;)

Gruß und so...

[sfxon]

"Du hast geschrieben, wenn das Programm/Prozess regelmäßig auf ereignisse reagieren soll...."

Vielleicht etwas ungünstig formuliert.
Die Crontab ruft einen Befehl in regelmäßigen Abständen auf. Damit muss man das Programm nur kurz starten.
Bei jedem Start prüft es einfach, ob eine neue Anweisung vorhanden ist oder nicht, und führt diese bei Bedarf aus.
Wenn nichts da ist, beendet sich das Programm einfach wieder. Das ist eine Abarbeitung auf asynchrone Art.
Die Programme sind nicht davon abhängig, dass das jeweils andere läuft. Damit werden Anwendungen weniger Fehleranfällig,
es geht aber die "Echtzeit" Steuerung verloren.

Es wäre auch vorstellbar, das ganze über eine Datenbank umzusetzen, und die Programme durchgehend laufen zu lassen.
Es könnte auch eine einfache Datei sein, die irgendwo geschrieben wird, und von beiden Prozessen genutzt wird (Einer schreibt, der andere liest und führt aus).
Damit erspart man sich die Programmierung von Netzwerk-Interfaces (z.B. Sockets) oder Thread-Kommunikation zwischen Programmen.
Letzteres sind Konzepte, die schon etwas aufwändiger sind.

[BeRsErKeR]

Ich hätte gerne einen Prozess, der ständig im Hintergrund läuft, natürlich selbst geschrieben.
Mir soll es jetzt möglich sein diesen Prozess von außen zu veranlassen irgendwelche Aufgaben zu erfüllen; z.B. ein Programm starten (EXE ausführen) oder Rechner runterfahren….oder was auch immer.

Ich hätte es gerne so, dass ich dazu eine zweite EXE aufrufe, ihr Parameter übergebe, und diese zweite EXE übergibt dann diese Parameter dem Prozess, der diese Parameter interpretiert und entsprechend darauf reagiert.
Ich habe aber keine Idee wie man dazu vorzugehen hat.
Wisst ihr etwas darüber? Könnt ihr mir Tipps geben?

(Es soll unter Windows laufen)

Mir würde da spontan ein Dienst einfallen und wie schon erwähnt Pipes. Wie auch schon erwähnt wären Sockets je nach Anforderung auch eine Lösung, vor allem wenn du auch Remote etwas machen willst.

Was mir aber noch nicht so ganz klar ist, ist warum du diesen Extraprozess benötigst, wenn du eh noch ein Tool zum Steuern schreibst. Wieso kann das nicht gleich die Aktionen ausführen, die du benötigst? Ich will dir das nicht ausreden - mich interessieren nur die Hintergründe.

[joggel]

Ich mußte erstmal überlegen wozu ich das gebraucht hatte.
Ich hatte das aber wieder sein gelassen.

Der Hintergedanke war, glaube ich:
Wir entwickeln hier auf einer SPS. Mein Kollege schreibt dazu ein Programm für die SPS.
Aus diesem SPS-Programm kann man EXEn aufrufen und ihnen auch Parameter übergeben.
Ich schreibe dann kleine Helfer-Programme, zB: öffnen eines PDF-Dokuments und an eine bestimmte Bildschirmposition positionieren...wuat ever.

Der Nachteil daran ist eben, dass man dann ein Rudel extra Programme hat, die alle unterschiedlich aufregufen werden müssen.

Nun war mein Gedanke, man könnte ja so einen Dienst schreiben, der ständig läuft, den man Parameter übergibt, und dieser dann unterscheidliche Aktionen ausführt.
So braucht man nur noch diesen einen Dienst auf der SPS und kein extra Rudel an zusätzlichen Helfer-Programmen.

Mein Kollege würde dann ein Programm aufrufen, dem ein Parameter übergeben; dieses Programm gibt den Parameter dann weiter an den Dienst, der dann die gewünschte Aktion durchführt.
Also braucht man dann nur noch 2 EXEn auf der SPS => den Dienst und das Kommunikations-Programm dazu, dass eben aus der SPS-Applikation aufgerufen wird.

[BeRsErKeR]

Hm aber da reicht doch auch ein Programm, welches direkt die Sachen ausführt. Einen Dienst braucht man doch dann gar nicht. Ein Programm, was alle Aktionen beherrscht und man kann diesem per Parameter sagen, was es tun soll. Das kann doch dann gleich direkt aufgerufen werden.

[Offtopic]Da ich hier auch gerade mit SPS und Simulationssoftware arbeite: Was benutzt ihr denn für eine SPS/Software und welche Programmiersprache? Klingt ja fast nach C. Ich muss mich hier noch mit good 'ol AWL rumschlagen. Zum Glück kann die Simulationssoftware schon etwas mehr in Richtung C. :)[/Offtopic]

[joggel]

Achso, kleiner Zusatz:

In diesem Programm was die ganze Zeit läuft und einen Dienst bereitstellt:
Das muß die ganze Zeit laufen, weil es an einem Netzwerk-Port die ganze Zeit lauscht und ggf auf Nachrichten reagiert ;)

[Edit]
Ach Du hast schon geantwortet^^

[Offtopic]Da ich hier auch gerade mit SPS und Simulationssoftware arbeite: Was benutzt ihr denn für eine SPS/Software und welche Programmiersprache? Klingt ja fast nach C. Ich muss mich hier noch mit good 'ol AWL rumschlagen. Zum Glück kann die Simulationssoftware schon etwas mehr in Richtung C. :)[/Offtopic]

Mein Kollege arbeitet mit CoDeSys(Logik) + Gallileo(GUI/HMI) [wobei wir wieder beim thema wären^^].
Und ich schreibe meine Helferprogramme mit C, aber das Entwickeln für SPS mit WinCE 6 ist sehr...naja...nervig. Da es sich kaum debuggen lässt, und kaum bis keine Bibliotheken dafür gibt.
Was es genau für SPSs sind:
Kann ich jetzt gar nicht so genau sagen...