[java] Best practice für Interaktion mit externen Programmaufrufen? - Seite 2

Seite 2 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/java_best_practice_fuer_interaktion_mit_externen_p_208309/page_2 - zur Vollversion wechseln!

Ringding schrieb am 26.06.2009 um 18:15

Ja aber auch nur, wenn man read aufruft; nicht einfach so im Hintergrund (was für mein Problem notwendig wäre), oder?

DirtyHarry schrieb am 28.06.2009 um 11:48

nein, im hintergrund nicht - aber auch dafür würde sich eine nebenläufiger thread empfehlen, der ständig ein read() oder readavail() macht

Ringding schrieb am 29.06.2009 um 08:09

Ja, mit einem Thread könnte man es natürlich machen. Aber wenn es auch ohne geht, ist das ein bisschen verschwenderisch.

DirtyHarry schrieb am 29.06.2009 um 12:00

Aber eigentlich gibts ja genau für dein Prob den BufferedReader - den kannst ja gelegentlich mit der Mehtode .ready() quälen ob Schon etwas "non-blocking" von ihm zu lesen ist, wenn gewünscht kannst du den auch mit einer eigenen Grösse initialisieren (über den Constructor)

watchout schrieb am 02.07.2009 um 11:35

Was genau ist verschwenderisch an einem Thread?

Und nochmal - Rufst du ein externes Programm auf und willst Zeitgemäß auf dessen Outputs reagieren, kommst du nicht rum um einen eigenen Thread. Dieser Thread hat dann exakt 0 CPU-Last während er blockt (was der Großteil der Zeit so sein wird wenn du nicht gerade ein Codec aufrufst o.Ä.), somit ist alles was er "verschwendet" ein paar kB RAM.

Harry: Stimmt schon, nur kommst du da sehr leicht in die Situation dass du den Buffer nicht oft genug liest.

Ringding schrieb am 02.07.2009 um 15:32

Zitat von watchout
Was genau ist verschwenderisch an einem Thread?

Das hängt immer davon ab, auf welchem System das Programm laufen soll. Auf kleinen Embedded-Systemen sind ein paar KB RAM unter Umständen schon recht viel.

Zitat

Und nochmal - Rufst du ein externes Programm auf und willst Zeitgemäß auf dessen Outputs reagieren, kommst du nicht rum um einen eigenen Thread.

In C schon, und ich vermute, dass es sowas auch in Java gibt, nur hab ich mich noch nicht damit beschäftigt.

watchout schrieb am 02.07.2009 um 23:34

Du meinst also ein Programm welches ständig einen Speicherbereich pollt (in ner Schleife, wwi) ist besser als ein 2. Thread (wohlgemerkt THREAD, nicht Process) welcher vor sich hinschlummert, und der vom OS dann von einem Software Interrupt aufgeweckt wird?
Von wieviel Bytes Hauptspeicher reden wir in deinem Embedded System? (Welches übrigens noch Java unterstützt)

Ich glaubs irgendwie nicht, aber wenn ich mal in der Situation bin schenk ich dir nen Keks

Ringding schrieb am 03.07.2009 um 11:05

Zitat von watchout
Du meinst also ein Programm welches ständig einen Speicherbereich pollt (in ner Schleife, wwi) ist besser als ein 2. Thread (wohlgemerkt THREAD, nicht Process) welcher vor sich hinschlummert, und der vom OS dann von einem Software Interrupt aufgeweckt wird?

Wer hat was von Polling gesagt? (Stichwort select)

Zitat
Von wieviel Bytes Hauptspeicher reden wir in deinem Embedded System? (Welches übrigens noch Java unterstützt)

Auf 32MB RAM laufen z.B. schon Java-Systeme im Embedded-Bereich.

watchout schrieb am 05.07.2009 um 03:11

Zitat von Ringding
Wer hat was von Polling gesagt? (Stichwort select)

Entweder du blockst oder du pollst, select blockt (wenn es das ist was ich denke), womit wir wieder beim Thema eigener Thread sind, weil mit nur einem Thread (welcher gerade blockt) Wird es schwer fallen zB. auf Eingaben vom User in einem UI zu reagieren.

Select ist find ich auch nur sinnvoll wenn du mehrere ähnliche Streams hast - oder wirklich einfach nicht anders kannst, weil in allen anderen Fällen hast du u.U. derart viel Aufwand beim herausfinden was da jetzt eigentlich passiert ist und wo du im Moment bist in deiner State Machine dass es besser ist einfach einen eigenen Thread zu machen (auch Speichermäßig). Mir wär das jedenfalls zu blöd außer ich hab wirklich Performance Probleme, das Programm soll ja auch noch wartbar sein.

Jetzt versteh ich aber auch endlich warum du das Webserver Beispiel gegeben hast, es dürfte ein paar geben die anstatt zu fork()en mit select arbeiten, soweit ich weiß funktioniert aber zB. Apache HTTPD mit fork - aus gutem Grund, weil select ist mal so überhaupt nicht Multi-prozessor/-core tauglich, dann ist ein fork()ed prozess welcher wirklich nur eine Connection behandeln muss wesentlich kleiner und den Sicherheitsaspekt sollte man auch nicht ignorieren. Gerade beim Webserver hast du dann auch Probleme wie Mehrteilige HTTP responses/requests etc. das is so schon mühsam (schon mal einen HTTP Client geschrieben?) aber wenn ich daran denke dass ich mehrere Connections mit einem einzigen Process behandeln muss ...
Wenn du dir die Apache MPM liste http://httpd.apache.org/docs/2.2/mod/ anschaust, siehst du auch zB. ausschließlich Multithread/Process Module, wobei die meisten sogar noch sowohl multithreaded als auch fork()ed sind
Nur das "event" Modul gibts da welches mehrere Threads die zB. nur KeepAlive sind zusammenfasst um Ressourcen zu sparen, ich wette aber dass auch der Thread dann fork()ed oder nen neuen Thread aufmacht sobald auf einem der KeepAlive Sockets was passiert.

Select in Java ... schon mal http://java.sun.com/javase/6/docs/a...ml#select%28%29 angeschaut? Scheint ja dem C-select zu ähneln, bin aber trotzdem kein Fan davon auch wenn ich mir schon begrenzte Anwendungsgebiete vorstellen kann (Wakeup Events, o.Ä.)

BTW: Ist dein Problem jetzt eigentlich das Gleiche wie vom SemteX oder ein anderes?

semteX schrieb am 06.07.2009 um 12:16

ich sag schonmal danke für die ausführungen, sehr interessant

Ringding schrieb am 29.08.2009 um 20:20

Ich hab mich jetzt mal hingesetzt und versucht, was Vernünftiges zu finden, aber anscheinend sind Threads wirklich die einzige Methode, um das korrekt hinzubekommen. Dieser Artikel sagt eigentlich alles, was gesagt werden muss, daher belasse ich es dabei…