Hi,

ich möchte in einem Programm eine Schleife ausführen. Aber das Hauptprogramm soll während der Verarbeitung dieser Schleife weiter laufen. Das kann ich ja mit fork machen. In dieser Schleife fülle ich einen Hash mit Werten. Wenn ich aber vor der Schleife ein fork mache, dann werden die Werte ja an einer anderen Stellen in den Speicher geschrieben. Wie kann ich denn mit dem geforkten Programm kommunizieren oder wie kommen ich an diese Werte ran.

versuchs mal über pipes - da ich leider keine Erfahrung hab - hier mal ein Artikel vom Linux-Magazin:

http://www.linux-magazin.de/Artikel/ausgabe/2001/08/Perl/perl.html

Gruss,
quetzal

ja, das hört sich gut an. Werde ich mir anschauen.

Danke..

Gruss
romulus\n\n

<!--EDIT|romulus|1084964180-->

Ueblicherweise loest man sowas mit threads. Wenn dein perl nicht mit threads-Unterstuetzung gebaut ist (gute Entscheidung :-), dann kann man stattdessen "forks.pm" versuchen. Das ist eine Threads-Emulation, die ueber fork() implementiert ist. Im Paket ist forks::shared enthalten, womit man Variablen in mehreren Prozessen bearbeiten kann.

Ja, ich würde es gerne ohne Threads lösen weil das Programm auch andere benutzen sollen (Sourceforge Projekt). Und leider sind die meisten binary perls ohne Thread support gebaut.

Ein mini test-skript macht schon das was ich will aber in meinem Programm geht irgendwie was schief. Ich habs jetzt auch ewig probiert, zuerst nur mit fork und eine pipe Verbindung und dann mit forks.pm aber leider passiert dann immer was komischen.

Letztlich bin ich drauf gekommen, dass wenn ich nur diesen Code in meinem Programm einfüge:

$r=fork();
if($r==0)
{
exit;
}

dass dann mein Programm nicht mehr richtig funktioniert obwohl da ja eigentlich gar nichts passiert.
Irgendwie scheint das modul Term::Screen nicht mehr zu funktionieren (glaube ich). Das brauch ich zur Steuerung des Programms über die Tastatur.
Kann sowas überhaupt sein ?
Bin langsam am verzweifeln...

So etwas kann passieren. Bei einem fork werden Sachen wie filehandles dupliziert, und END { ... }-Bloecke und DESTROY-Methoden werden auch im geforkten Prozess ausgefuehrt. Einige Probleme kann man umgehen, indem man statt exit() CORE::exit() verwendet (ueblicherweise bei Verwendung von Tk oder anderen Modulen, die exit() ueberschreiben) oder sogar POSIX::_exit (damit kann man vermeiden, dass END-Blocke ausgefuehrt werden). Einige Module haben Hilfsmittel, um das automatische Destroy in einem der beiden Prozesse zu vermeiden (z.B. DBI mit InactiveDestroy).

Vielleicht hat Term::Screen auch Probleme, wenn geforkt wird. Eine Loesung koennte sein, so frueh wie moeglich zu forken (bevor Term::Screen verwendet wird). Oder beim Autor von Term::Screen um Rat fragen --- vielleicht hilft es, wenn einige Filehandles im Kindprozess geschlossen werden.

Vielen dank für die ausführliche Antwort. Genau das ist auch mein Problem. Es ist definitiv das Term::Screen modul. Wenn ich ein mini-fork und exit vor dem 'use Modul' mache dann gibts keine Probleme. Leider konnte ich das Problem mit den anderen exit-Methoden noch nicht lösen. Und leider brauch ich diese funktion öfter mal d.h. ich kann es nicht einfach davor machen ausser beim erstem mal vielleicht. Aber das bringt mich schon mal viel weiter danke dafür schonmal. Vielleicht werde ich mal den Entwickler von Term::Screen anschreiben und mal fragen ob ihm das Prblem bekannt ist.

Kurz noch zur Sache:
ich brauch diese Funktion für einen Player (frontent für mplayer). Was der so macht kann man sich mal anschauen unter http://mplay.sf.net
Da lese ich mittels MP3::Info die länge von MP3s aus. Das mache ich in einer Schleife. Und während dessen (bei vielen MP3s kann das schon lange dauern) kann ich den Player nicht weiter verwenden :( sondern muss abwarten oder abbrechen.
Gibt es denn evtl. auch eine andere Methode wie ich das machen könnte ...
danke

#
#\n\n

<!--EDIT|quetzalcoatl|1085167945-->

mit Term::ReadKey gibts keine Probleme. Den kann ich auch hernehmen. Danke für eure Hilfe.