[Vienna-pm] Vars in sub max {..}

peter pilsl pilsl at goldfisch.at
Fri Feb 3 07:10:43 PST 2006


Bernd Petrovitsch wrote:

ähhh ... mit deinem zeilenumbruch ist etwas schwer nicht in ordnung ;)

das explizite löschen von hashes und arrays hat zwei haken:

i) man übersieht immer etwas, wenn man verschachtelte strukturen verwendet

ii) das explizite löschen kann zuwenig sein. Wenn eine struktur 
referenzen auf code hat, der über eval definiert wurde, zB

Hier hilfts nix ausser eine eigene GC zu schreiben, die zB im zuge des 
destroys von objekten oder teilweise auch beim verlassen von methoden 
aufgerufen wird.

aber ich denke, hier gibts zwei ansätze:

einerseits den ansatz, der meint, ein gutes programm braucht keine gute 
GC, weil der programmierer exakt weiss wo was genau steht
und der ansatz der meint, der aufwand für dieses wissen ist ab einer 
bestimmten datenkomplexität zu gross und eine GC daher wesentlich 
effizienter.

lgp


> On Fri, 2006-02-03 at 14:02 +0100, peter pilsl wrote:[...]> Man sieht, dass der Speicherplatz bei jedem Aufruf ein anderer ist, der> sich aber auch mal wiederholen kann.> > Die genaue Funktion der Speicherfreigabe ist nicht nur Aufgabe von perl> und keinesfalls deterministisch.> > Was fix ist:> bei jedem Aufruf der sub wird $x neu erzeugt. An welchem Speicherplatz> ist nach aussen zufällig.  Bei Ende der sub wird $x wieder freigegeben> und damit im perl-internen sinn auch zerstört.
> Wenn es keine Referenzen drauf gibt.
> [...]> Aber die Aufgabe ist extremst komplex und es gibt speicherstrukturen,> die perl überfordern und es gibt immer wieder bugs in der> garbage-collection von perl und dann gibt es natürlich prinzipielle> probleme wie zirkuläre referenzen  $a->{x}-{y}=[1,2,\$a,4,5];  die von> einem counter-basierten garbage-collector wie perl gar nicht aufgelöst> werden *können*.
> Dafür ist der GC simpel. Wenn man solche Strukturen aufbaut (und Angstfor Speicherleaks hat), dann kann man immer noch explizit Hashes undArray löschen - stören wird das kaum können).
> [...]> Bisher komme ich selten umhin, mir eigene GarbageCollectoren für> grössere Projekte zu basteln (kämpfe aber dennoch seit März mit einem> unentdeckten mem-leak in einer mod_perl-application :)
> Tja ....
> 	Bernd-- Firmix Software GmbH                   http://www.firmix.at/mobil: +43 664 4416156                 fax: +43 1 7890849-55          Embedded Linux Development and Services
> _______________________________________________Vienna-pm mailing listVienna-pm at pm.orghttp://mail.pm.org/mailman/listinfo/vienna-pm
> 


-- 
mag. peter pilsl
goldfisch.at
IT- & dataconsulting
tel: +43 650 3574035
tel: +43 1 8900602
fax: +43 1 8900602 15
pilsl at goldfisch.at


More information about the Vienna-pm mailing list