Autorelease Pool Verständnisfrage.

[Jamsven]

Hallo,
der Autorelease Pool (arp) schickt dem betroffendem Objekt ja eine relesae Nachricht, wenn dieses verarbeitet wurde.

Wann ist das genau? Direkt nach der return Zeile?
Wenn dem so wäre müsste man doch bei einem Methodenaufruf welcher ein temporäres Objekt zurückgibt dieses doch sofort ein "retain" schicken, damit es sich nicht Dealloziert.
Das wäre ja kein großes Problem, aber wie sieht es hier mit verschachtelten Messages aus.?

 

[below]

Das ist frühestens dann, wenn das nächste mal die Run Loop erreicht wird.

Alex

 

[Jamsven]

Was ist genau eine Runloop unter ObjectiveC ?

Im Index meiner beiden Bücher steht nichs der gleichen...

 

[below]

Was ist genau eine Runloop unter ObjectiveC ?

Im Index meiner beiden Bücher steht nichs der gleichen...

Welche Bücher wären das?

Alex

 

[Jamsven]

Hillegrass: Cocoa Programmierung für Mac OS X 3. Auflage
Objective-C und Cocoa von Rodewig und Negm-Awad 2. Auflage

Bin bei beiden noch nicht durch, jedenfalls habe ich im Stichwortverzeichnis nichts der gleichen gefunden.
Beim Hillegrass wird ab Seite 98 auf dem Autorelease pool eingegangen.

 

[below]

Schau Dir im Hillegass das Diagramm auf Seite 37 an.

Amins Buch ist im Büro, da kann ich erst morgen nachsehen.

Alex

 

[Jamsven]

Hmm bei mir ist dort nur Abbildung 2.11: Das Textfeld zentrieren.

Edit:
Hab es gefunden, bei mir ists auf Seite 52 Abb: 2.26 "Der zeitliche Ablauf" und S.53 Abb. 2.27: "Die Rolle des Window Servers".
Hillegrass spricht aber hier von einer "Main Event Loop (Hauptereignisschleife)". Nur Hillegrass erklärt das ganze mit einem GUI Programm, aber wie sieht das mit einer Kommandozeilen App aus?

Jetzt habe ich glaube ich dank "Amins Buch" den dreh heraus.
Hillegrass scheint mir da nicht so sehr ins Detail zu gehen, Lob an dieser stelle den anderen beiden Cracks

EDIT2:
Mir ist heut Morgen noch etwas aufgefallen:
Wenn ich ein Termial-Programm schreibe, sollte ich dann doch besser statt den "convenience allocator" den entsprechenden Initialisierer aufrufen, da wir keine Run Loops im Terminal haben. Sonst würden Speicherlecks entstehen. Aber wie sieht so etwas mit von Methoden erhaltenen Objekten aus. Immerhin werden diese im ARP markiert und somit bis zum Ende des Programms im Speicher sein.

 

[below]

Jetzt habe ich glaube ich dank "Amins Buch" den dreh heraus.
Hillegrass scheint mir da nicht so sehr ins Detail zu gehen

Was genau war Dein Verständnisproblem?

"convenience allocator" den entsprechenden Initialisierer aufrufen, da wir keine Run Loops im Terminal haben. Sonst würden Speicherlecks entstehen. Aber wie sieht so etwas mit von Methoden erhaltenen Objekten aus. Immerhin werden diese im ARP markiert sein und somit bis zum Ende des Programms im Speicher sein.

Auch in Kommandozeilen Applicationen kann man eine Run Loop haben ...

Aber davon abgesehen: In diesen Fällen ist ein lokaler Autorelease Pool die einzig richtige Vorgehensweise. Denn Du weisst selbst bei "alloc init" nicht, was das Framework sonst noch so auf den ARP wirft.

Oder Du verwendest CoreFoundation. Da gibt es keinen ARP.

Alex

 

[Amin Negm-Awad]

[…]Jetzt habe ich glaube ich dank "Amins Buch" den dreh heraus.
Hillegrass scheint mir da nicht so sehr ins Detail zu gehen, Lob an dieser stelle den anderen beiden Cracks

Büdde!

Das Thema Speicherverwaltung wird bei Hillegass in der Tat nur angeschnitten. Glücklicherweise hat sich allerdings zwischenzeitlich die Apple-Doku dazu verbessert.

EDIT2:
Mir ist heut Morgen noch etwas aufgefallen:
Wenn ich eine Termial-Programm schreibe, sollte ich dann doch besser statt den "convenience allocator" den entsprechenden Initialisierer aufrufen, da wir keine Run Loops im Terminal haben. Sonst würden Speicherlecks entstehen. Aber wie sieht so etwas mit von Methoden erhaltenen Objekten aus. Immerhin werden diese im ARP markiert sein und somit bis zum Ende des Programms im Speicher sein.

Auch dazu schreibe ich was.

Der Punkt ist jedoch, wie bereits von Alex angesprochen, dass man nie wissen kann, ob die Cocoa-Klassen nicht den ARP benutzen. Beim iPhone wird das allerdings (heute nur noch eingeschränkt) so empfohlen. Da werden also die Apple-Entwickler drauf geachtet haben.

Generell tendiere ich aber auch zur Lösung mit lokalen ARP. In dem Abschnitt über den ARP weise ich ja darauf hin, dass es Problemstellungen gibt, die sich ohne ihn gar nicht sauber lösen lassen. Lies hierzu etwa Seite 157 unten. Etwas später, Seite 171 f., stelle ich ja auch den lokalen ARP vor.

 

[Jamsven]

Was genau war Dein Verständnisproblem?

Naja nach Hillegrass hatte ich den Run Loop als Technik nur für die GUI verstanden.
Dann geht er im Abschnitt 4.3.3 auf temporäre Objekte ein. Er erwähnt zwar eine Ereignisschleife, aber da dieses Kapitel sich an Kommandozeilen Programme orientiert, war ich verwirrt. Speicherlecks verschwinden eh wenn das Programm terminiert, was es ja direkt nach dem ARP release macht. Ergo ist ein programmglobaler ARP eher sinnlos.

Auch in Kommandozeilen Applicationen kann man eine Run Loop haben ...

Aber davon abgesehen: In diesen Fällen ist ein lokaler Autorelease Pool die einzig richtige Vorgehensweise. Denn Du weisst selbst bei "alloc init" nicht, was das Framework sonst noch so auf den ARP wirft.

Oder Du verwendest CoreFoundation. Da gibt es keinen ARP.

Alex

Aha ok, das erklärt einiges. Man muss halt ab und zu den Müll leeren und ne neue Mülltüte einsetzen.
Bei ner GUI.app kommt zyklisch eine Putzfrau die einem das abnimmt.

CoreFoundation nutze ich nicht, ich halte mich primär an Hillegass' Buch, da es auf Xcode 3 basiert und Features wie den Garbage Collector anspricht. Amins Buch habe ich leider nur in der "Tiger" Ausgabe zur Hand, welches ich aber trotzdem wegen des Umfanges zu schätzen gelernt.

OT: Kennt einer von euch ein Tutorial/Buch welches OCUnit behandelt?

 

[Peter Maurer]

Dann geht er im Abschnitt 4.3.3 auf temporäre Objekte ein. Er erwähnt zwar eine Ereignisschleife, aber da dieses Kapitel sich an Kommandozeilen Programme orientiert, war ich verwirrt. Speicherlecks verschwinden eh wenn das Programm terminiert, was es ja direkt nach dem ARP release macht. Ergo ist ein programmglobaler ARP eher sinnlos.

Ohne genau zu wissen, was dazu im Hillegas steht: Du sollst den Autorelease-Pool ja auch innerhalb der Schleife leeren. Im einfachsten Fall etwa so...

for (aMonsterObject in lotsOfMonsterObjects) {
	aLocalAutoreleasePool = [[NSAutoreleasePool alloc] init];
	[aMonsterObject performMemoryConsumingTaskAndCreateTonsOfTemporaryObjects];
	[aLocalAutoreleasePool release];
}

Mit GarbageCollector kannst Du statt dessen auch regelmaessig -drain sagen. Und es gibt auch Leute, die darauf stehen, den Autorelease-Pool nur alle soundsoviel Durchlaeufe zu leeren, aber das muss man dann einfach per Instruments ausloten, falls es wirklich drauf ankommt.

Generell halte ich die Assoziation zwischen lokalem Autorelease-Pool und GUI-App jedenfalls fuer eine Assoziation in der falschen Dimension, sozusagen. Ich sehe die Verbindung eher zu Situationen, in denen man viele Daten/Objekte umsetzt, und das kann gerade in einem Hintergrundprozess gerne mal der Fall sein.

PS: Gewoehn' Dich nicht zu sehr an den Garbage Collector. Auf dem iPhone z.B. gibt's den nicht, und Du hast doch wieder selbst die Verantwortung, hinter Dir aufzuraeumen. (Insofern ist das iPhone ein gutes Entwickler-Erziehungsinstrument: Man muss sowohl mit Bildschirmflaeche als auch Speicher haushalten wie seit Jahren nicht. )

 

[Jamsven]

Ohne genau zu wissen, was dazu im Hillegas steht: Du sollst den Autorelease-Pool ja auch innerhalb der Schleife leeren. Im einfachsten Fall etwa so...

for (aMonsterObject in lotsOfMonsterObjects) {
	aLocalAutoreleasePool = [[NSAutoreleasePool alloc] init];
	[aMonsterObject performMemoryConsumingTaskAndCreateTonsOfTemporaryObjects];
	[aLocalAutoreleasePool release];	// bzw. -drain, je nach Konfession ;)
}

Es gibt auch Leute, die darauf stehen, den Autorelease-Pool nur alle soundsoviel Durchlaeufe zu leeren, aber das muss man dann einfach per Instruments ausloten, falls es wirklich drauf ankommt.

Der Amin macht das in seinem Buch. Naja hier fängt wohl das Laufzeittuning an.
Hillegass behandelt lokale ARP leider nicht in seinem Kapitel(4) für Speicherverwaltung.

Generell halte ich die Assoziation zwischen lokalem Autorelease-Pool und GUI-App jedenfalls fuer eine Assoziation in der falschen Dimension, sozusagen. Ich sehe die Verbindung eher zu Situationen, in denen man viele Daten/Objekte umsetzt, und das kann gerade in einem Hintergrundprozess gerne mal der Fall sein.

ack

PS: Gewoehn' Dich nicht zu sehr an den Garbage Collector. Auf dem iPhone z.B. gibt's den nicht, und Du hast doch wieder selbst die Verantwortung, hinter Dir aufzuraeumen. (Insofern ist das iPhone ein gutes Entwickler-Erziehungsinstrument: Man muss sowohl mit Bildschirmflaeche als auch Speicher haushalten wie seit Jahren nicht. )

Ich durfte laut Autor, die Referenzzähler überspringen. Aber das wäre halbherzig und das mag ich nicht. Speicherverwaltung ist ein wichtiges Thema und deswegen kritisiere ich auch immer diese "Java Pest" in den Hochschulen. Aber das ist ein ganz anderes Thema.