Mir ist in letzter Zeit nichts derartiges aufgefallen.
Immer noch OT, ich weiß bloss nicht, wohin damit ...
Heißt das, es gab früher mal Probleme, die in etwa so lagen, wie meine Schilderung es beschreibt ?
Das Konto ist (wie man sehen kann) schon sehr alt, früher habe ich aber nichts geschrieben und da fiel es mir nicht auf.
Gab es da mal bekannte Fehler ? Wenn ja, wie wurden die behoben ? Ich kann nicht einmal die Suchfunktion sinnvoll nutzen, da *jeder* Versuch mit "Error - please ..." oder 404 auf dem Server endet (da kriege ich dann noch die Info, daß die PHP-Seite für eine erweiterte 404-Beschreibung nicht vorhanden ist) ... bei der Suche ist es offenbar sogar egal, ob ich angemeldet bin oder nicht (also mit Keks oder ohne oder auch mit Dauerkeks).
Um auszuschließen, daß es am Useraccount (im IPPF) liegt, würde ich gerne mal jemandem per PM ein Kennwort zukommen lassen, damit er/sie sich an meiner Stelle einmal einloggen kann. Hinterher ändere ich dann selbstverständlich das Kennwort.
Freiwillige vor ...
Ich bin sicher, dass der Overhead für das Pattern-Matching kleiner ist, als einen neuen Prozess zu starten, die benötigten Libraries zu laden und zu linken.
Solange wir das nicht ausmessen und zwar an einer sehr großen Zahl von Aufrufen, damit es evident wird, bleibt es wohl akademisch.
Der Aufwand für ein 'fgrep' (und darauf wird es - vermute ich aber auch nur, weil ich es selbst so machen würde - verkürzt, wenn keine Permutationen möglich sind) dürfte wesentlich geringer sein (im Extremfall in C nur ein strstr pro Zeile, was je nach Prozessorarchitektur ggf. auch bis auf Maschinencode-Ebene ohne Loops o.ä. funktioniert), als der für die state machine eines regex-Matching.
Und geladen und dynamisch gelinkt sollten die Libs untereinander ja eigentlich schon sein (sofern sie geshared werden können, reicht dann das Mapping in den Speicher des neuen Prozesses), nur die Auflösung der Referenzen auf die Library-Funktionen (also das dynamische Linken gegen die Libs) müßte der Loader noch machen, wenn nicht sogar der Code des 'grep' zwischen den beiden Instanzen geshared werden kann.
Da das in unserem Falle normalerweise alles Busybox-Applets sind, müßte nach meinem Verständnis sogar mit jedem beliebigen anderen Applet geshared werden (also die ganze Busybox insgesamt nur einmal geladen und gelinkt werden). Der Rest sollte dann nur anhand der cmdline entschieden werden.
Allerdings ist das Erstellen des Prozesses sicherlich wirklich nicht zu verachten, besonders auch wenn es zu zusätzlichen Kontextwechseln kommt, weil beim Schreiben in die Pipe gewartet werden muß, bis das 'grep -q' am anderen Ende die Buffer leert. Wenn man es wirklich mal messen will, müßte man wohl auch noch unterschiedlich große Prozesslisten testen.
Der effizienteste Weg um die PID eines selbst geschriebenen Skripts herauszufinden ist, die PID beim Start in eine Datei zu schreiben und nachher aus dieser Datei zu lesen. Ggf. kann man noch prüfen, ob unter dieser PID auch der richtige Prozess läuft, man muss dafür aber nicht alle Prozesse durchsuchen.
Das klappt - bei mir - leider auch nicht immer bzw. es wäre bei mehreren Instanzen zusätzlicher Aufwand zu treiben, um einen entsprechenden Parameter zu übergeben. Das macht gerade dann in meinen Augen keinen Sinn macht, wenn das Script ansonsten eigentlich parameterlos arbeitet und man die ganze Behandlung erst noch einbauen müßte.
Und ob man die Liste durchläuft (als Script ohnehin bei mir fix und fertig vorhanden und ohne Rücksicht auf die Unterschiede zwischen Binaries und Shell-Scripten benutzbar) oder zusätzliche Tests für "orphaned pid files" einbaut, hängt sicherlich auch von der zusätzlichen 'utilization' durch das Durchlaufen der Prozessliste ab, wobei ja auch die Häufigkeit dieses Vorgangs eine Rolle spielt.
Von der fehlenden *realistischen* Möglichkeit, Scripte im SquashFS einfach um das Speichern eines PID-Files zu erweitern, mal ganz abgesehen ...
