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

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

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

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.

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

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?

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…