Здесь часто в предложениях прокомментировать свой код, да и просто в разных фрагментах опубликованного кода проскакивают вызовы методов Thread.Abort для завершения работы вновь созданного потока. На самом деле, это является не самой удачной практикой и существует масса способов получить "неожиданное" состояние приложения. На самом деле, это верный способ получить рассогласованное состояние приложения, дедлоки и утечки ресурсов.
В общем, если интересно — велкам:
"О вреде метода Thread.Abort".
Здравствуйте, SergeyT., Вы писали:
ST>Здесь часто в предложениях прокомментировать свой код, да и просто в разных фрагментах опубликованного кода проскакивают вызовы методов Thread.Abort для завершения работы вновь созданного потока...
В догонку — тема на StackOverflow:
http://stackoverflow.com/questions/3923457/is-cs-using-statement-abort-safe
Самая гадость, что и Thread.Abort, и Thread.ResetAbort используются самими фреймворком, особенно в System.Web. А ещё из-за этих нехороших людей приходится писать
lockInvoker.Invoke(() => DoSomething(strange));
вместо
using(new NonReentrantLock(lockKey))
{
// ...
}
Здравствуйте, SergeyT., Вы писали:
ST>Здесь часто в предложениях прокомментировать свой код, да и просто в разных фрагментах опубликованного кода проскакивают вызовы методов Thread.Abort для завершения работы вновь созданного потока. На самом деле, это является не самой удачной практикой и существует масса способов получить "неожиданное" состояние приложения. На самом деле, это верный способ получить рассогласованное состояние приложения, дедлоки и утечки ресурсов.
ST>В общем, если интересно — велкам: "О вреде метода Thread.Abort".
Я чего-то не понимаю или такая запись:
var file = File.OpenWrite(fileName);
try
{
// Записываем информацию в файл
}
finally
вместо
FileStream file = null;
try
{
file = File.OpenWrite(fileName);
// Записываем информацию в файл
}
finally
Сама по себе — верный путь к граблям неисполненного finally даже без учета Thread.Abort() ?
Здравствуйте, Nikolay_P_I, Вы писали:
Даже
FileStream file = null;
try
{
file = File.OpenWrite(fileName);
// Записываем информацию в файл
}
finally
Не сработает — ThreadAbortException может произойти внутри OpenWrite (после нативной OpenFile и до возвращения результата). Или после OpenWrite и перед сохранением результата в переменную.
Тут ничего страшного — GC всё подберёт, а вот для управления глобальным состоянием using-и лучше не использовать.
Здравствуйте, SergeyT., Вы писали:
Начиная с .Net Framework 4.0 эта ситуация наконец-то исправлена и оператор lock(syncRoot) разворачивается компилятором таким образом ...
Здесь я бы добавил одно слово.
