[bcn-pm] Perls i forks

Xevi Ezquerra Elias ezquerra at hades.udg.es
Sat Mar 20 03:10:45 CST 2004


Salutacions a tots/es,

Crear un proces fill sense que quedar "zombie" (perdi parentesc amb el pare).
El cost es elevat ( o molt elevat) ja que per crear el proces independent es
fan 2 forks, aquest seria el codi:

#!/usr/bin/perl
use strict;

my ($pid, $pid2, $i);

	$pid = fork();

	if ($pid < 0) {
		print "Soc el proces fill i no puc fer Fork()!!!\n";
	# Process Fill
	} elsif ($pid == 0) {
	
		# Faig un Fork
		$pid2 = fork();
		
		if ($pid2 < 0) {
			print "Soc el proces fill i no puc fer Fork()!!!\n";
		# Finaltzo el Pare convertin-lo en fill
		} elsif ($pid2 > 0) {
			exit(0);
		}
		
		# Codi del Fill que ja no te parentesc amb el  pare i és Independent
		for ($i =0; $i<5; $i++) {
			print "\nMissatge\t nº $i, process NoZombie Independent PID=[$$]\n";
			sleep $i;
		}
		
		exit(0);
	}
	
	
	waitpid($pid, 1);
	print "\nHe Finalitzat el Proces el meu PID=[$$]\n";

Bé tampoc se si et serà útil pel teu problema, intenta ser una idea.

Una idea per fer servir una cua de processos seria fer servir un "namedPipe",
 on s'escriuen el els noms del processos que s'han d'executar i que s'han
finalitzat.
Aquest programa va llegint constantment de la namedPipe, quan li arriba un
proces l'apunta a la cua i l'executa tot fent un fork i exec. Perque la cua
sapiga que un proces ha finalitzat no fara res, sinó el propi proces que s'ha
iniciat desde la cua amb un exec ha d'escriure a la namePipe que ha
finalitzat. Encara que això que estic dient no serveix si ho executes en
diferents màquines , la idea seria la mateixa pero en comptes de fer servir
una "namedPipe" s'hauria de fer servir  sockets.

Salut!.





On Thu, 18 Mar 2004 23:13:40 +0100, Lluís Ribes wrote
> Hola,
> 
> Sóc en Lluís Ribes, aquest dies estic fent un sheduler per llançar 
> treballs sobre una plataforma GRID. He decidit fer-ho en perl per la 
> seva portabilitat i la sencillessa a l hora de debugar errors. El 
> scheduler és molt sencill, i actualment encara més, per què el que 
> fa és llansar uns 14 treballs paral.lels cada 200 segons sobre 5 
> màquines diferents. Aquest 14 treballs són cadascú un fork, i ja 
> m´he trobat amb un problema, i és que hi ha un limit de zoombies 
> generats pels forks que poden estar actius, de tal forma, que 
> després de 8 torns de generar 14 treballs, el pare a arrivat al 
> limit de forks que pot fer i peta.
> 
> Aixó ho he resolt parcialment fent que el fork que genera 14 
> treballs cada cop, estigui en un fitxer perl que és cridat per 
> unaltre procés perl mitjançant system. Es pot fer algo per evitar el 
> zoombies? cal dir que el pare no pot bloquejar-se fent un wait 
> perquè sinó és perd la paral.lització.
> 
> Per unaltre costat, he volgut evolucionar el scheduler, i ara vull 
> que s estiguin executant 1 treball per màquina, i quan una màquina 
> es queda sense treballs, doncs li assigno un. Per aixó continuo fent 
> servint forks, però ara, aquest fills han d´enviar  informació  que  
> han acabat la feina al pare per a que es dongui compte i llanci 
> unaltre treball a la màquina descarregada. Vull evitar fer servir 
> memòria compartida, ja que em reduïria la portabilitat tal com molt 
> bé m´ha comentat en Alexm  
> (mersi ;) ) .Fer-ho amb pipe no m he és útil , o no sé com fer-ho 
> per a que pugui crear una pipe per cada fill, entrar en un bucle 
> d´espera que algun fill possi senyal de que ja està i llansar 
> unaltre fill amb una pipe nova sense bloquejar el pare pel bloqueig 
> de les pipes,
> 
> Com ho veieu, creieu que aquest escenari és óptim pel lleguatge PERL?
> 
> Gràcies!,
> 
> lluis,
> 
> _______________________________________________
> llista dels Barcelona-pm
> Barcelona-pm at mail.pm.org
> http://mail.pm.org/mailman/listinfo/barcelona-pm
> BCN Perl Mongers: http://barcelona.pm.org






More information about the Barcelona-pm mailing list