ПК>by default, Finalize methods are not called for unreachable objects when an application exits so that the application may terminate quickly
Не читай Рихтера за 2000 год. Он писал про какую то левую бету(первая версии книжки также была о ней). Все работает. На всякий случай даже проверил:
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace Test
{
class Test
{
public class TestGC
{
public TestGC(){}
~TestGC(){Console.WriteLine("exit");}
}
static void Main()
{
{
TestGC t=new TestGC();
}
}
}
}
Здравствуйте, GlebZ, Вы писали:
GZ>>>Не-а, будет вызываться. Хотя бы при выходе из программы. AVK>>Совсем не обязательно. GZ>Example?
The Finalize method might not run to completion or might not run at all in the following exceptional circumstances:
Another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain and so on). Because the runtime attempts to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely.
The process terminates without giving the runtime a chance to clean up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification.
The runtime continues to Finalize objects during shutdown only while the number of finalizable objects continues to decrease.
ПК>by default, Finalize methods are not called for unreachable objects when an application exits so that the application may terminate quickly
Еще одна цитата, на этот раз из MSDN
The Finalize method might not run to completion or might not run at all in the following exceptional circumstances:
Another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain and so on). Because the runtime attempts to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely.
The process terminates without giving the runtime a chance to clean up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification.
The runtime continues to Finalize objects during shutdown only while the number of finalizable objects continues to decrease.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Если под отсутствием утечек понимать освобождение памяти по крайней мере в момент завершения программы, то утечек вообще нигде не будет.
Запусти эту программу
using System;
namespace GCTest
{
class Program
{
const int testCount = 10;
const int objectCount = 1000;
const int iterCount = 100000;
const int minObjSize = 1000;
const int maxObjSize = 10000;
static void PrintGCInfo()
{
for (int i = 0; i <= GC.MaxGeneration; ++i)
Console.WriteLine("Generation {0} collection count = {1}", i, GC.CollectionCount(i));
}
static void Test()
{
byte[][] arr = new byte[objectCount][];
Random r = new Random();
for (int j = 0; j < iterCount; ++j)
{
arr[r.Next(arr.Length)] = new byte[r.Next(minObjSize, maxObjSize)];
}
}
static void Main(string[] args)
{
for (int i = 0; i < testCount; ++i)
{
Test();
Console.WriteLine("Test {0}/{1}", i + 1, testCount);
PrintGCInfo();
Console.WriteLine();
}
}
}
}
Тут хорошо видно что сборка второго поколения происходит довольно активно.
Про первое я вспомнил, просто не говорил так как это вопрос о том, что криминальная ошибка привела к невызову finalize. Про второе, тоже можно было догадаться. Возможно еще будут проблемы при вызове а ля StackOverflow OutOfMemory exception. Правда может он подпадает под пункт два.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>А зачем его звать-то ? Он сам вызывается при выходе из зоны видимости. S>Если у тебя все разрушается при выходе из области видимости, то никакой GC не нужен. Да и мемори менеджер тоже — стек аллокатор будет более чем достаточен.
Смотря для чего. А если я не знаю размер требуемой памяти в момент компиляции?
ПК>by default, Finalize methods are not called for unreachable objects when an application exits so that the application may terminate quickly
Все так, но по жизни проблем это не создает. Два случая в которых не вызваются финалайзеры:
1. Завис один из финалайзеров.
2. Процесс удален как-то по варварски.
Первый случай — баг. И но довольно легко отлавливается. К тому же я таких проблем еще не встречал.
Второй случай просто не интересен, так как при завершении приложения все внешние сслки на ресурсы автоматически закрывает ОС. А внутрениие уже никого не колышут.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
ПК>>Если под отсутствием утечек понимать освобождение памяти по крайней мере в момент завершения программы
AVK>Почему обязательно в момент завершения? Судя по янусу уж раз в час то уборка 2-го поколения вызывается.
Статистика по моему Янусу:
78 уборок второго поколения с момента запуска. Янус был запущен в 4:00 10.11.2005.
Общее потребленное процессорное время 12 с половиной часов.
То есть при активной работе сборка идет чаще чем раз в час. При теневой работе практически не происходит. Что и логично.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали: S>>Если у тебя все разрушается при выходе из области видимости, то никакой GC не нужен. Да и мемори менеджер тоже — стек аллокатор будет более чем достаточен.
CS>Смотря для чего. А если я не знаю размер требуемой памяти в момент компиляции?
Неважно. Стек ограничивает только порядок освобождения.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
sch>>...Сборщик мусора он реализовал путем подсчета ссылок;
CS>reference counting как одно из средств memory management — работает. И кстати на определнных задачах CS>эффектвнее других механизмов GC в разы. А какие проблемы ты видишь?
sch>>а проблему кольцевых ссылок он решает следующим образом: при завершении работы программы сборщик мусора просто освобождает все неосвобожденные участки
CS>И чего? Так работает любой GC.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, c-smile, Вы писали: S>>>Если у тебя все разрушается при выходе из области видимости, то никакой GC не нужен. Да и мемори менеджер тоже — стек аллокатор будет более чем достаточен.
CS>>Смотря для чего. А если я не знаю размер требуемой памяти в момент компиляции? S>Неважно. Стек ограничивает только порядок освобождения.
Здравствуйте, VladD2, Вы писали:
VD>Второй случай просто не интересен, так как при завершении приложения все внешние сслки на ресурсы автоматически закрывает ОС.
Второй тоже баг. Максимум использование Net из unmanaged — это интерфейсы COM. При этом FreeLibrary внешним процессом не должны вызываться. В самом Net все без эксцессов. VD>А внутрениие уже никого не колышут.
Могут колыхать. Буффер файла будет потерян.
Здравствуйте, GlebZ, Вы писали:
VD>>Второй случай просто не интересен, так как при завершении приложения все внешние сслки на ресурсы автоматически закрывает ОС. GZ>Второй тоже баг. Максимум использование Net из unmanaged — это интерфейсы COM. При этом FreeLibrary внешним процессом не должны вызываться. В самом Net все без эксцессов.
Какой на фиг FreeLibrary? Кому он интересен? Ну, и проблемы КОМ-а есть проблемы КОМ-а. Не нужно их к дотнету привязывать.
VD>>А внутрениие уже никого не колышут. GZ>Могут колыхать. Буффер файла будет потерян.
Что?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какой на фиг FreeLibrary? Кому он интересен? Ну, и проблемы КОМ-а есть проблемы КОМ-а. Не нужно их к дотнету привязывать.
Поэтому и считаю что пункт второй может произойти также в результате баги.
VD>>>А внутрениие уже никого не колышут. GZ>>Могут колыхать. Буффер файла будет потерян. VD>Что?
У тебя идет буфферизированная запись в файл. В случае если не был вызван диспозе, то файл то будет закрыт, но данные буфера будут потеряны.
Здравствуйте, GlebZ, Вы писали:
GZ>У тебя идет буфферизированная запись в файл. В случае если не был вызван диспозе, то файл то будет закрыт, но данные буфера будут потеряны.
Ну, то есть если у меня идет не буферизированная запись и она обрываетя на полуслове, то это нормально?
Забавно!
Может простно нужно понять, что ненормальное завершение прилоежния есть ненормальное завершение и при этом обсуждать проблемы финалайзеров просто смешно. Деструкторы ведь тоже могут не вызваться.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Может простно нужно понять, что ненормальное завершение прилоежния есть ненормальное завершение и при этом обсуждать проблемы финалайзеров просто смешно. Деструкторы ведь тоже могут не вызваться.
Собственно это мы и пытаемся друг другу доказать
Здравствуйте, GlebZ, Вы писали:
VD>>Может простно нужно понять, что ненормальное завершение прилоежния есть ненормальное завершение и при этом обсуждать проблемы финалайзеров просто смешно. Деструкторы ведь тоже могут не вызваться. GZ>Собственно это мы и пытаемся друг другу доказать
Тогда нужо понять о чем мы говорим.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
VD>>>Может простно нужно понять, что ненормальное завершение прилоежния есть ненормальное завершение и при этом обсуждать проблемы финалайзеров просто смешно. Деструкторы ведь тоже могут не вызваться. GZ>>Собственно это мы и пытаемся друг другу доказать
VD>Тогда нужо понять о чем мы говорим.
Здравствуйте, c-smile, Вы писали:
sch>> Mini C++ это тот же интерпретатор подмножества бейсика, который он дал в свой книжке "Профессиональное программирование на Turbo C" двадцать лет назад CS>So what? Еще одно поколение программеров научится писать инетрпретаторы. CS>Простота изложения проблемы Шилдтом очень помогает на ранних преиодах освоения. CS>Провернно на личном опыте.
Ужасненько.(с)Цири
Учиться писать интерпретаторы нужно по небезысветсной Dragon Book. Делать это по Шилдту -- это примерно то же, что учиться управлять реактивным истребителем по какой-нибудь "Управление любым средством перевижения за 21 минуту" 8))
Про первое я вспомнил, просто не говорил так как это вопрос о том, что криминальная ошибка привела к невызову finalize. Про второе, тоже можно было догадаться. Возможно еще будут проблемы при вызове а ля StackOverflow OutOfMemory exception. 
Правда может он подпадает под пункт два.
1.1.4 stable rev. 510
