Diskussion: GC / Dispose verwenden um eine Nacharbeitung vieler Objekte zu machen

[Ralph Erdt (2)]

Hallo.

Ich habe hier eine .. seltsame .. Idee, und würde das mal gerne Leuten vorstellen, die Ahnung haben und Feedback einholen.

Ich habe hier ein Programm, welches Dateien extrahiert, dann jede Datei in eine TODO Liste einträgt. Diese Liste wird abgearbeitet, dabei können diese Dateien wieder extrahiert werden, ..., etc. Gelöst ist das mit Woker-Threads, die sich immer einen Eintrag aus der Liste holen (Eintrag wird aus der Liste gelöscht) und dann abarbeiten.

Da die extrahierten Dateien / Verzeichnisse auch gelöscht werden müssen, aber ich keine Ahnung habe, wann das komplette Paket abgearbeitet wird (OK, ich könnte Liste führen..), habe ich diese .. Idee:
Jedes Objekt (Datei) aus einem Extrakt bekommt eine Referenz auf ein Spezialobjekt ("Deleter"). Dieser Deleter hat nur das Dispose überschrieben: Verzeichnis löschen. Idee: Sobald die Dateien abgearbeitet wurden, werden die Objekte auch nicht mehr referenziert. Also werden diese Objekte vom GC entfernt. Irgendwann wurden alle Objekte eines Extrakts entfernt, nun gibt es keine Referenz auf den Deleter mehr. Nun wird das Deleter Objekt entfernt und das Löscht das Verzeichnis im Dispose.

Das einzige Problem was ich habe: Wird der Optimierer nicht die Referenz rausoptimieren, weil das ja im Code nicht angesprochen wird?

Was haltet Ihr davon?

Danke und Grüße
Ralph

[Christian Marquardt]

Seltsame Idee, die Abarbeitung eines Programmteiles an die Löschung des Objektes zu binden. Somit erhält man einen unbestimmten Zeitpunkt wann das gemacht wird.
Warum nicht eine 2. Todo-Liste von Anfang an anlegen. Ist die erste leer, wird die zweite abgearbeitet mit dem löschen.
Warum nicht eine HashMap (Dictionary) als Todo-Liste benutzen. Der Eintrag wird nicht aus der Liste gelöscht, sondern als "schon bearbeitet" gekennzeichnet. So bleibt die Liste erhalten

[Ralph Erdt (2)]

Die Idee ist: Es ist mir Wurst WANN es passiert, es sollte nur passieren. Und: Faulheit sowie Experimentierfreude..

[Ralf Jansen]

Niemand ruft Dispose von selbst auf auch nicht der GC. Dispose ist für deterministisches selbstverwaltetes Verhalten und mit keinerlei Automatik verheiratet. Der GC ruft nur den Finalizer auf. Du müßtest also selbst Dispose aus dem Finalizer aus aufrufen und checken ob nicht schon jemand anderes von außen Dispose benutzt hat damit es nicht mehrmals passiert.
Letztlich ist die Idee eher ein Mißbrauch und ich würde davon abraten. Ein intelligentere Queue die nicht einfach nur die Files enthält sondern eben auch die ganze Aufgabe zu der auch das löschen am Ende gehört wäre anzuraten. Diese Queue sollte auch die Aufgaben nachhalten die Gerade in Bearbeitung sind. Ein Workerthread sollte rückmelden wenn er fertig ist damit der Queue die Chance hat selbst den Zustand der gerade in Bearbeitung befindlichen Dinge zu überwachen und bei Zeiten dann die Löschen Aufgabe rausgeben damit sich ein Workerthread drum kümmert.

[Womble]

Mag sein das ich Dein Problem nicht verstanden habe, aber ich hätte das File einfach am Ende der Verarbeitung gelöscht, der Worker hat ja irgendwann seine Arbeit getan und als letztes kommt eben "weg mit dem File". Danach kommt eine Rekursive Prüfung auf das Verzeichnis. Ist da noch was drinnen? Wenn nein, weg damit, und das so lange bis ein von Dir definiertes Ausgangsverzeichnis erreicht ist. Sonst wird evtl. mehr Verzeichnisstruktur gelöscht als gewünscht nur weil diese gerade zufällig leer ist.

[Ralph Erdt (2)]

Sorry, dass ich erst jetzt antworte. Probleme...

So einfach mit dem Löschen nach Verarbeitung ist es leider nicht. Bei einigen Dateien werden noch andere Dateien gebraucht. Hintergrund: Analyse Installationsdateien (privates Projekt): Beispiel: Einige MSI brauchen noch die CAB Dateien, damit man die richtig analysieren kann. Oder auch die Visual C Redist einer bestimmten Version braucht alles auf einmal, sonst weigern sich die Windows-APIs. Daher kann ich das Verzeichnis erst löschen, wenn wirklich alle Dateien abgearbeitet wurden.

Ich habe es jetzt "richtig" gelöst. Gab aber einige Probleme, da ich da noch einige Flags einbauen musste, an die ich vorher nicht gedacht habe, geschweige denn das ganz schützen (Mutex). Mit einer IDispose Lösung wäre das alles nicht notwendig gewesen. Aber ja, das ist schon ein ziemlicher Mißbrauch (@Ralf Jansen: Klar muss man das IDispose Pattern implementieren..).