Mein erster Eindruck von readFile war ein Kompromiss zwischen seiner Bequemlichkeit und der Möglichkeit, die Dateideskriptoren länger als nötig geöffnet zu lassen, ohne sie zu schließen. Als ein Experiment habe ich das folgende (sehr praktische) Programm ausprobiert und dachte, es könnte sich ersticken, wenn ich versuche, tausend offene Dateideskriptoren zu verwalten:
Aber es macht wirklich einen ziemlich guten Job, Dateideskriptoren zurückzufordern; die Zählung wird nie über 70 hinausgehen:
%Vor% Wie ist das passiert? Ist es nur, dass die Werte von contents GC'd werden, und mit ihnen die nicht mehr referenzierten Dateideskriptoren? Oder gibt es einen separaten Mechanismus zum Verwalten von Datei-Deskriptor-Ressourcen? Was auch immer der Mechanismus ist, es scheint ziemlich gut zu funktionieren - wie kannst du wissen, wann es am besten ist, hClose explizit zu verwenden?
Es ist besser, Ressourcen nur dann explizit zu schließen, wenn Sie eine Ressourcenbeschränkung auf niedriger Ebene haben, die Sie manuell erzwingen können.
Die zu berücksichtigenden Fälle:
finally oder bracket ) Die Haddock-Dokumentation für System.IO hat dies zu sagen:
GHC-Hinweis: Ein Handle wird automatisch geschlossen, wenn der Garbage Collector erkennt, dass das Programm keine Referenz mehr enthält. Es wird jedoch im Allgemeinen nicht empfohlen, sich auf dieses Verhalten zu verlassen: Der Garbage Collector ist unvorhersehbar. Verwenden Sie nach Möglichkeit eine explizite hClose, um Handles zu schließen, wenn sie nicht mehr benötigt werden. GHC versucht derzeit nicht, Dateideskriptoren freizugeben, wenn sie abgelaufen sind. Es liegt in Ihrer Verantwortung sicherzustellen, dass dies nicht geschieht.
Tags und Links haskell