Hi Ratti, hi Liste, ich programmiere zwar schon seit Jahren nicht mehr in Perl, dieser Thread interessiert mich aber weil ich mich intensive mit "Multiprocessing" und "Multithreading" auseinander gesetzt habe, und das Problem welches hier auftaucht, ich nur vom Multithreading her kenne. Vorweg eine Definition was ich unter Multiprocessing und Multithreading versteh: _Multiprocessing:_ Das erstellen eines neuen Prozesses mit fork, der vollkommen unabhängig vom Parentprozess ist. Die einzige Kommunikation zum Parentprozess besteht über einen Returncode, der mit wait vom Parentprozess abgefragt werden kann/muß. Stirbt der Parentprozess, fängt init (Prozess# 1) den Childprozess auf, und der Childprozess wird damit zu einem Deamon. Alles an Variablen, Filedescriptoren etc. sind im Childprozess unabhängig und seperat vorhanden. _Vorteil:_ extrem robust _Nachteil:_ Alle Komunikation zwischen Parent- und ChildProzess muß seperat über sharedmemory, semaphoren oder pipes programmiert werden. _Multithreading:_ Das erstellen eiens neuen Threads mit einem in der Prog.-sprache dafür vorgesehenen Befehls, er ist nicht unabhängig, und teilt sich alle "Variablen", Filedescriptoren etc. mit den anderen Threads. _Vorteil:_ einfache Komunikation zwischen den Threads _Nachteil:_ empfindlich, der Absturz eines Threads, reißt die anderen mit, wenn es nicht programmtechnisch abgefangen wird. Multithreading kann der Linuxkernel AFAK seit 2.0, vorher war nur Multiprozessing möglich. Zurück zum Thema: Hier scheint sich genau der Nachteil vom Multithreding bemerkbar zu machen. Meine Vermutung ist, der Befehl fork in Perl startet nicht einen eigenen Prozess, sondern macht nur einen eigenen Tread im Interpreter dafür auf. Neben dem Verhalten sprechen noch einige andere Aussagen dafür: Bernhard Walle wrote:
On Mon, 29 Dec 2003 at 01:37 (+0100), Ferdinand Ihringer wrote:
Geht Forken eigentlich auch unter Windows? Das müsste ja eigentlich wie kill oder waitpid Unixspezifisch sein. In Perl ja. Als System call existiert es aber nicht.
Der kleinste gemeinsame Nenner ist hier Multithreading. Siehe auch: http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=perlfork <Zitate> NOTE: As of the 5.8.0 release, fork() emulation has considerably matured. However, there are still a few known bugs and differences from real fork() that might affect you. See the "BUGS" and "CAVEATS AND LIMITATIONS" sections below. Note that the issues discussed here are not applicable to platforms where a real fork() is available _and Perl has been configured to use it._ In the eyes of the operating system, pseudo-processes created via the fork() emulation are simply threads in the same process. If the parent process is killed (either using Perl's kill() builtin, or using some external means) all the pseudo-processes are killed as well, and the whole process exits. </Zitate> Diese forkemulation gibt es seit 5.6.1. Vorher galt sie als experimentel. Kann es sein das Perl mitlerweile standardmäsig so kompiliert/configuriert wird, das es auch unter Linux dise emulation nutzt, damit es sich auf Linux und Windows (M$ hat wohl diese emulation gesponsert) gleich verhält? Joerg Rossdeutscher wrote:
Daher die Idee: Ein Prozess startet einen zweiten Prozess, der die eigentliche Arbeit leistet. Wenn dieser Prozess Segfaultet, lass ihn wegbrechen - der erste Prozess merkt das, kennt auch die verursachende Datei und forkt einen neuen Prozess, der mit der nächsten Datei fortfährt.
s. o. bist du sicher das es ein eigener Prozeß ist?
Mein Problem: Warum stirbt der Parent-Prozess mit? Wieso?
Weil es keinen Parent-Prozess gibt, sondern nur einen Thread.
Das sollte so nicht sein.
Bei einem Thread schon, nicht bei einem Prozess. hth cu Gerald