Здравствуйте, Дарней, Вы писали:
Д>А вот тут ты не совсем прав. GC забивает на финализацию только в том случае, когда происходит закрытие процесса.
Я совсем прав. Финалайзеры вызываются зи отдельного потока
Д>Если же происходит работа в обычном режиме, то тред финализации подвисает намертво и висит, пока не будет закрыт процесс. Так что все время жизни процесса будет происходить утечка памяти (понятно, что при этом для объектов без финалайзера никаких проблем не будет). Д>По крайней мере, таково положение в 1.0. и 1.1 Д>Насчет 2.0 не знаю
И где ты взял такие свленения?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я совсем прав. Финалайзеры вызываются зи отдельного потока
я знаю
тем не менее — пока этот поток висит, ни один объект с финалайзером не будет освобожден
VD>И где ты взял такие свленения?
просто небольшой эксперимент — можешь сам проверить, кстати.
еще про это написано у Рихтера. "Программирование на платформе .NET" (первое издание), с. 396
RTFM
Здравствуйте, Дарней, Вы писали:
Д>я знаю Д>тем не менее — пока этот поток висит, ни один объект с финалайзером не будет освобожден
Он не может висеть более определенного промежутка времени (если не ошибаюсь 2 секунд).
VD>>И где ты взял такие свленения?
Д>просто небольшой эксперимент — можешь сам проверить, кстати.
Ты лучше не советуй другим, а сам попробуй. Я то пробовал не раз. Никаких проблем нет.
Д>еще про это написано у Рихтера. "Программирование на платформе .NET" (первое издание), с. 396 Д>RTFM
И что же ты там вычитал. Почти уверен, что просто не понял доконца, что написано.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Он не может висеть более определенного промежутка времени (если не ошибаюсь 2 секунд).
тестовый пример — в студию!
VD>Ты лучше не советуй другим, а сам попробуй. Я то пробовал не раз. Никаких проблем нет.
значит, плохо пробовал
VD>И что же ты там вычитал. Почти уверен, что просто не понял доконца, что написано.
Перепечатывать из книги нет никакого желания. Не могу поверить, что у тебя под рукой нет ни одного экземпляра.
Когда кажется — креститься надо. Если можешь показать, что именно я там неправильно понял — флаг в руки. Если нет — попрошу воздержаться от ничем не обоснованных утвержений.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Естественно, BlackBox тоже для каждого объекта хранит указатель на дескриптор типа, так что реальный размер объекта на самом деле чуть больше чем сумма размеров его полей, ну и что из этого следует? Какая, по большому счету, разница имеет ли объект размер V = 4*N байтов или V = 4*N + delta, где delta ~ 8 байтов, в тех случаях когда N = 2000, ..., N = 8000? Думаю разницы никакой...
Маленькая поправка не по существу: delta = 4.
Здравствуйте, Дарней, Вы писали:
Д>Перепечатывать из книги нет никакого желания. Не могу поверить, что у тебя под рукой нет ни одного экземпляра. Д>Когда кажется — креститься надо. Если можешь показать, что именно я там неправильно понял — флаг в руки. Если нет — попрошу воздержаться от ничем не обоснованных утвержений.
Здравствуйте, vdimas, Вы писали:
V>да ты хоть страницу скажи, интересно стало
Можно и без Рихтера. Тест примерно такой:
using System;
using System.Threading;
class Test
{
static void Main()
{
Test t = new Test();
GC.Collect();
Thread.Sleep(-1);
}
~Test()
{
while (true)
{
Thread.Sleep(1000);
Console.WriteLine(DateTime.Now);
}
}
}
VD>>Ты лучше не советуй другим, а сам попробуй. Я то пробовал не раз. Никаких проблем нет.
Д>значит, плохо пробовал
Так попробуй хорошо.
VD>>И что же ты там вычитал. Почти уверен, что просто не понял доконца, что написано.
Д>Перепечатывать из книги нет никакого желания. Не могу поверить, что у тебя под рукой нет ни одного экземпляра.
А накой он мне под рукой?
Д>Когда кажется — креститься надо.
Перекристился?
Д> Если можешь показать, что именно я там неправильно понял — флаг в руки.
Для этого ты должен процитировать участок на основании которого ты сделал подобное заключение.
Д> Если нет — попрошу воздержаться от ничем не обоснованных утвержений.
Примени эти слова к себе.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так попробуй хорошо.
using System;
using System.Threading;
class Test
{
class TestClass1
{
~TestClass1()
{
while (true)
{
Thread.Sleep(1000);
Console.Write("1 ");
Console.WriteLine(DateTime.Now);
}
}
}
class TestClass2
{
~TestClass2()
{
while (true)
{
Thread.Sleep(1000);
Console.Write("2 ");
Console.WriteLine(DateTime.Now);
}
}
}
static void Main()
{
TestClass1 t1 = new TestClass1();
t1 = null;
TestClass2 t2 = new TestClass2();
t2 = null;
while (true)
{
GC.Collect();
}
}
}
Проверено на VS2003
Нетрудно убедиться, что финалайзер одного из объектов выполняется бесконечно долго, а другой объект так же бесконечно стоит в очереди freachable. Что и требовалось доказать.
VD>А накой он мне под рукой?
Я всегда думал, что любой толковый програмер под .NET должен иметь эту книгу под рукой. Или как минимум ее прочитать. И понять
VD>Для этого ты должен процитировать участок на основании которого ты сделал подобное заключение.
Там написано очень просто.
"Если метод Finalize .... попадает в бесконечный цикл, этот особый поток блокируется, и ни один метод Finalize больше не может быть вызван. Это очень скверная ситцация: приложение больше не сможет освобождать память, занятую завершаемыми объектами, и на протяжении всей работы приложения будет происходить утечка памяти."
Ваши комментарии?
VD>Примени эти слова к себе.
Я свои слова и до этого прекрасно обосновал. А теперь — еще лучше Так что если ты сумеешь доказать, что я не прав, то я готов съесть свою собственную шапку
Здравствуйте, Дарней, Вы писали:
Д>А вот тут ты не совсем прав. GC забивает на финализацию только в том случае, когда происходит закрытие процесса. Д>Если же происходит работа в обычном режиме, то тред финализации подвисает намертво и висит, пока не будет закрыт процесс. Так что все время жизни процесса будет происходить утечка памяти (понятно, что при этом для объектов без финалайзера никаких проблем не будет).
ну и что это доказывает?
разумеется финализация производиться в отдельном потоке, в порядке очереди.
для объектов без финализатора утечек не будет.
Здравствуйте, Дарней, Вы писали:
Д>Нетрудно убедиться, что финалайзер одного из объектов выполняется бесконечно долго, а другой объект так же бесконечно стоит в очереди freachable. Что и требовалось доказать.
Нда. Значит я спутал с завершением процесса. При завершении процесса он точно срубается в течении нескольких секунд.
VD>>А накой он мне под рукой?
Д>Я всегда думал, что любой толковый програмер под .NET должен иметь эту книгу под рукой. Или как минимум ее прочитать. И понять
Вот я когда-то ее прочитал и куда-то засунул. Откровенно говоря так-как попала ко мне в руки она слишком поздно, толку от нее особого небыло. Было несколько интересных моментов, но пользы от них на практие не много. Те же финалайзеры довольно бесполезны сами по себе, чтобы на них закладываться. Хотя труд конечно основательный. Рихтер держит марку.
Д>Там написано очень просто. Д>"Если метод Finalize .... попадает в бесконечный цикл, этот особый поток блокируется, и ни один метод Finalize больше не может быть вызван. Это очень скверная ситцация: приложение больше не сможет освобождать память, занятую завершаемыми объектами, и на протяжении всей работы приложения будет происходить утечка памяти." Д>Ваши комментарии?
Да, все верно. Только это не говорит о том, что ЖЦ перестанет работать, или поток финализации не будет убит никогда.
Д>Я свои слова и до этого прекрасно обосновал.
Сейчас вот обосновал. А до этого не очень то.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>это доказывает, что утечка все-таки может происходить — даже если ссылок на объект в коде не осталось
Финалайзеры настолько недетерминированная вещь, что закладваться на них нельзя даже если бы они обеспечивали 100%-ую гарантию отрабатывания.
Их можно рассматривать только как дополнительный сервис дающий еще один шанс безалаберной программе. Я вот как-то ни одного за три года не написал (если не считать тесты).
V>>для объектов без финализатора утечек не будет.
Д>у большого количества классов он есть
Ошибашся. У относительно малого. К тому же даже если он есть — это еще не значит, что объект попадет в очередь финализации. Большинство объектов у которых реализован финалайзер так же реализован и IDisposable.Dispose(), который обычно делается по следующеей схеме:
public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
то есть после вызова Dispose объект принудительно удаляется из очереди финализации. Так что в эту очередь попадают или потерянные объекты, или не очень добротно написанные.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Нда. Значит я спутал с завершением процесса. При завершении процесса он точно срубается в течении нескольких секунд.
угу, так оно и есть
VD>Вот я когда-то ее прочитал и куда-то засунул. Откровенно говоря так-как попала ко мне в руки она слишком поздно, толку от нее особого небыло. Было несколько интересных моментов, но пользы от них на практие не много. Те же финалайзеры довольно бесполезны сами по себе, чтобы на них закладываться. Хотя труд конечно основательный. Рихтер держит марку.
ИМХО, в .NET финалайзеры вообще не надо было реализовывать — Dispose вполне достаточно. А то слишком уж часто встречаются примеры неправильного использования финалайзеров
VD>Да, все верно. Только это не говорит о том, что ЖЦ перестанет работать, или поток финализации не будет убит никогда.
Здравствуйте, VladD2, Вы писали:
VD>то есть после вызова Dispose объект принудительно удаляется из очереди финализации. Так что в эту очередь попадают или потерянные объекты, или не очень добротно написанные.
в принципе — так оно и есть.. так что это можно считать еще одной причиной не использовать финалайзеры
Выходиит, "по-честному" GC завалить невозможно.
Что неудивительно в силу его внутренней простоты и отсутствия каких-либо революционных "ноу-хау", доселе неиспытанных в индустрии.
Финалайзеры вызываются зи отдельного потока
