Здравствуйте, kov_serg, Вы писали:

_>Меня вымораживает что using не Abort safe. И это везде во всём .net на уровне компилятора.
_>Хотя что мешает сделать нормально. В блоке using заблокировать abort.
_>И SafeHandle и SupreCondomHandle тут не помогут.

Это огонь!


_>В результате Thread.Abort вообще получается функция которая призвана разрушить программу, а не остановить поток.

Не программу, а поток. Thread.Abort вносит элемент недетерменированности и на этом форуме 10^10 раз говорилось об его нежелательности. Т.е. люди стреляют себе в ногу, а потому громко чем-то недовольны.

_>А так получается что писать примерно так надо:
_>

_>try{}finally {
_>  getSomeSafeHandle(out safeHandle);
_>}
_>

_>Но такого нигде не видел. И главное всем пофиг.

Всякие библиотечные примитивы синхронизации фреймворка таким кодом писаны. В коде мс я такую конструкцию регулярно видел.

Здравствуйте, Sinix, Вы писали:

V>>Код одинаковый, что в статье, что в посте.

S>Мы точно про эту ссылку говорим?
S>Код там другой, 1-в-1 каноничный dispose pattern.

Да, и чем код из поста отличается?

Здравствуйте, Sharov, Вы писали:

_>>В результате Thread.Abort вообще получается функция которая призвана разрушить программу, а не остановить поток.

S>Не программу, а поток. Thread.Abort вносит элемент недетерменированности и на этом форуме 10^10 раз говорилось об его нежелательности. Т.е. люди стреляют себе в ногу, а потому громко чем-то недовольны.
Зачем вообще тогда Thread.Abort() оставили доступной для обычных смертных?

Здравствуйте, nigh, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>using(new Timer())

_>>Точно я выделил не managed ресурсы и вруг завершился до регистрации в using и приплыли.
N>никто в здравом уме в конструкторе не выделяет unmanaged ресурсы без try-finally.

Открою секрет: using это и есть try-finally

Здравствуйте, DarthSidius, Вы писали:

DS>Здравствуйте, nigh, Вы писали:

N>>Здравствуйте, kov_serg, Вы писали:

_>>>using(new Timer())

_>>>Точно я выделил не managed ресурсы и вруг завершился до регистрации в using и приплыли.
N>>никто в здравом уме в конструкторе не выделяет unmanaged ресурсы без try-finally.

DS>Открою секрет: using это и есть try-finally
открою другой секрет: using это не только try-finally.

Здравствуйте, kov_serg, Вы писали:

S>>Не программу, а поток. Thread.Abort вносит элемент недетерменированности и на этом форуме 10^10 раз говорилось об его нежелательности. Т.е. люди стреляют себе в ногу, а потому громко чем-то недовольны.
_>Зачем вообще тогда Thread.Abort() оставили доступной для обычных смертных?
Идиоты, сэр (с)

когда Thread.Abort делали, просто скопировали идею из JVM. Когда практика показала, сколько из-за него проблем, его начали активно "не рекомендовать", но backwards compartibility это надолго

Здравствуйте, Vladek, Вы писали:

V>Да, и чем код из поста отличается?
Да мелочи в основном.
Типа отсутствия обязательного protected virtual void Dispose(), проверок на IsDisposed не там, где надо (поле надо бы volatile сделать) и бага в подарок: для воскрешённого объекта Dispose() не запрещает вызов финалайзера. Плюс необходимость в вспомогательных полях для передачи состояния между DisposeManaged / Unmanaged.

А, ну и ваш вариант немножко сложнее допилить под потокобезопасный dispose.

По отдельности ничего страшного, по совокупности — лучше заменить это собрание потенциальных граблей на гарантированно рабочий вариант.

Здравствуйте, nigh, Вы писали:

DS>>Открою секрет: using это и есть try-finally
N>открою другой секрет: using это не только try-finally.


Продолжай.

Здравствуйте, nigh, Вы писали:

DS>>Открою секрет: using это и есть try-finally
N>открою другой секрет: using это не только try-finally.

using — это try и Dispose в finally
В конструкторе смысла в using или try-finally — нет. Есть смысл в try, а catch блоке Dispose и throw;
Предположим, ты опечатался про finally

Здравствуйте, DarthSidius, Вы писали:

DS>Здравствуйте, nigh, Вы писали:

DS>>>Открою секрет: using это и есть try-finally
N>>открою другой секрет: using это не только try-finally.

DS>using — это try и Dispose в finally
DS>В конструкторе смысла в using или try-finally — нет. Есть смысл в try, а catch блоке Dispose и throw;
DS>Предположим, ты опечатался про finally

Из конструкции

using(IDisposable a=createA()) {
...
}

Получаем такое

{
  IDisposable a=null;
  try { 
    a=createA();
    ...
  } finally {
    if (a!=null) a.Dispose();
  }
}

Хотя, логично было бы, ожитать такое

{
  IDisposable a=null;
  try { 
    try {} finally { a=createA(); }
    ...
  } finally {
    if (a!=null) a.Dispose();
  }
}

Именно эта непоследовательность компилятора мене не нравится.

Здравствуйте, kov_serg, Вы писали:

{
    ... 
    try {} finally { a=createA(); }
    ...
}

Это уже откровенный перебор. К чему это?

Здравствуйте, kov_serg, Вы писали:

_>Из конструкции ... получаем такое
Ну блиин. Спецификацию языка читать всё-таки надо. Вот такое получаем:

using (ResourceType resource = expression) statement;
// will be transformed into
{
   ResourceType resource = expression;
   try {
      statement;
   }
   finally {
      if (resource != null) ((IDisposable)resource).Dispose();
   }
}

_>Хотя, логично было бы, ожитать такое
Короткий ответ: не спасёт.
Подробно: У Реймонда Чена (гуру по приседаниям с совместимостью с клиентским софтом) есть отличное правило: перед тем, как что-то советовать всегда думай, что будет, если пожелание сбудется. Обычно результат несколько не совпадает с ожидаемым

В нашем случае ситуация принципиально не изменится. Если конструктор бросит исключение по любой другой причине, то присваивание a = "созданный объект" не отработает, и, соответственно, в внешний finally придёт null ref.
Упс.

В сумме, плюс: есть шанс вызвать Dispose() при обработке Thread.Abort(). Учитываем, что Thread.Abort по факту не используется.
Минус: небольшой хит по перфомансу под x86 при обработке исключений, что-то около 3-5% емнип.

Учитываем правило minus 100 points, получаем declined.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, kov_serg, Вы писали:


S>

S>{
S>    ... 
S>    try {} finally { a=createA(); }
S>    ...
S>}
S>

S>Это уже откровенный перебор. К чему это?
Это чтобы Thread.Abort() можно было использовать.

И если его вредно использовать то почему метод никто не пометил как не рекомендуемый к использованию. Механизм-то есть.

public sealed class Thread ...
  [Obsolete("мы против абортов")]
  public void Abort();
  [Obsolete("используйте другой язык")]
  public void Abort(Object stateInfo);
...

Я вообще радуюсь реализации многопоточности где за выделенные ресурсы отвечает тот кто их выделил, но если его остановить — то никто за них не отвечает.
Более того внятного механизма останова и не предлагают. В результате имее кучу вариантов: кто во что горазд.

Здравствуйте, kov_serg, Вы писали:


S>>Это уже откровенный перебор. К чему это?
_>Это чтобы Thread.Abort() можно было использовать.

_>И если его вредно использовать то почему метод никто не пометил как не рекомендуемый к использованию. Механизм-то есть.
_>

_>public sealed class Thread ...
_>  [Obsolete("мы против абортов")]
_>  public void Abort();
_>  [Obsolete("используйте другой язык")]
_>  public void Abort(Object stateInfo);
_>...
_>

Ну оставили, для себя и своих нужд хотя бы. А обычным смертным пользоваться этим механизмом не рекомендуют. Тут как с выключением компьютера -- можно "пуск->завершение работы", а можно шнур выдернуть. В каких-то редких случаях может шнур и надо выдергивать, но обычно лучше действовать по другому. Я вот не встречал код, где использовался бы Thread.Abort.

_>Я вообще радуюсь реализации многопоточности где за выделенные ресурсы отвечает тот кто их выделил, но если его остановить — то никто за них не отвечает.
_>Более того внятного механизма останова и не предлагают. В результате имее кучу вариантов: кто во что горазд.

начиная с .net 4.0, TPL, taskcompletionsource.

UPD: меня занесло -- не taskcompletionsource, а CancellationToken. Благодарю, Sinix.

Здравствуйте, DarthSidius, Вы писали:

DS>Здравствуйте, nigh, Вы писали:

DS>>>Открою секрет: using это и есть try-finally
N>>открою другой секрет: using это не только try-finally.

DS>using — это try и Dispose в finally
DS>В конструкторе смысла в using или try-finally — нет. Есть смысл в try, а catch блоке Dispose и throw;
DS>Предположим, ты опечатался про finally
батенька, прежде чем нести чушь, почитайте во что разворачивается using (ildasm в помощь). Или просто почитайте, что умные люди говорят. Помимо try и Dispose в finally там есть еще if. Что приводят к занятным спецэффектам, когда thread.abort вызывается в середине конструктора.

Здравствуйте, Sharov, Вы писали:

S>начиная с .net 4.0, TPL, taskcompletionsource.

CancellationToken наверно?

Здравствуйте, nigh, Вы писали:

DS>>using — это try и Dispose в finally
DS>>В конструкторе смысла в using или try-finally — нет. Есть смысл в try, а catch блоке Dispose и throw;
DS>>Предположим, ты опечатался про finally
N>батенька, прежде чем нести чушь, почитайте во что разворачивается using (ildasm в помощь). Или просто почитайте, что умные люди говорят. Помимо try и Dispose в finally там есть еще if. Что приводят к занятным спецэффектам, когда thread.abort вызывается в середине конструктора.

Твой if сути заданного вопроса не меняет.
Ну так зачем using либо try-finally в конструкторе? За исключением экзотических случаев.