Moin, Danke für deine Erklärungen. Ich bohren mal etwas nach: Am Mi, den 31.12.2003 schrieb Gerald Goebel um 00:10:
Joerg Rossdeutscher wrote:
Am Di, den 30.12.2003 schrieb Gerald Goebel um 20:19:
Joerg Rossdeutscher wrote:
komisch finde. There /is/ no such process. It died already! Damned.
Doch er existiert noch, er ist weder running, noch sleeping, sondern ein zombi.
Wie kommst du da drauf? Er wurde sauber mit "exit" beendet.
Mit dem exit kannst du ja auch noch was zurückgeben, z. B. 0 für richtig ausgeführt, oder -1 für Fehler. An wen soll das denn gehen?
Ich kann doch normalerweise jeden Prozess (solange er nicht innerhalb von Kernel-Routinen hängt) abschiessen. Wieso soll das hier anders sein?
Also nochmal: Prozesse, die von einem Prozess erzeugt wurden, sich beendet haben und die nicht erwartet werden, werden zu Zombies, und stehen damit noch immer zur Abholung in der Prozess-Tabelle bereit.
Es spielt also keine Rolle, ob sauber beendet wurde oder nicht.
Kannst du "Abholung" definieren? Und noch eine Verständnisfrage: 1. Ich dissoziiere den Prozess ja (setsid). Das sollte eigentlich (technisch) die Abhängigkeit zwischen den Prozessen beenden. Ich habe das noch nicht getestet, aber theoretisch sollte Child sogar weiterlaufen, wenn Parent beendet wird. 2. Nachdem das Programm durchgelaufen ist und auch ein paar mal geforkt hat, beendet es sich ordnungsgemäß. Ein anschliessendes "ps faux" zeigt keine Prozesse mehr. Dann ist doch alles in Ordnung, oder?
Es besteht ja auch die Möglichkeit, das der Prozess auf mehreren Wegen mit exit beendet wird, zum Beispiel weil etwas falsch gelaufen ist, dann möchtest du doch unter umständen wissen, ist der Prozess ganz durchgelaufen, oder ist irgendwo ein Fehler aufgetreten, während dein Parentprozess zwischenzeitlich etwas ganz anderes gemacht hat.
Für dich könnte das eine Rolle spielen, bei den fontlingen. Wielange muß der Prozeß immer wieder neu angeschmissen werden, er stürzt vieleicht 1mal ab, 16 mal 100 mal, bei 2000 Schriften 10.000 Schriften. Wie willst du das steuern? Mit ner Zufallszahl, Counter?
Das mit "Zufallszahl" verstehe ich jetzt nicht... Ich möchte, daß das Child Previews berechnet. Er bekommt Filenamen übergeben und generiert aus dem Font ein PNG. Entweder semmelt er dabei weg, dann wird der Font (weil kaputt) übersprungen und ein neues Child wird generiert. Oder aber es hat geklappt - dann darf der Prozess weiterleben und bekommt den nächsten Dateinamen. Wenn alle Fonts durch sind, bekommt Child ein Signal, sich normal zu beenden. Das das Child sich in diesem Test hier mittendrin gelegentlich selbst beendet, dient nur der Crash-Simulation. Sprich: Das Child wird genau so oft nachgestartet, wie es unerwartet abbricht. (Da sollten noch ein paar Sicherheitsabfragen rein, nach dem Motto "1000mal forken? Hier stimmt was nicht!" - aber jetzt mal ohne Sicherheitsdenke.)
Nach dem waitpid dir die pid des Childprozesses zurückgegeben hat, steht ser return/exitcode in '#?', dh. du untersuchst den exitcode und entscheidest dann, was weiter geschehen soll.
Der Exitcode ist gar nicht mal so interessant - die Tatsache eines "unbefohlenen Beendens" sagt eigentlich schon alles. (Im RealLife dann doch wieder, weil z.B. die Platte voll sein könnte oder so - lassen wir das hier mal aussen vor). Steh ich auf'm Denkschlauch? Ich sehe einfach kein Problem mehr. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/