Pull to refresh

Comments 12

А чего это MS не любит эту практику, прерывать выполнение потока, а если он в файл в это время пишет или формирует ответ сервера клиенту? Все не любят эту практику, а за использование надо руки отрывать и более не подпускать к компьютеру. Данная функция просто убивает контроль над завершением потока. Ну не надо изначально так делать и при портировании пусть переписывают код на нормальные модели прерывания работы потоков.
Имхо, все таки иногда можно грохнуть поток, если есть полная уверенность, что завершение ничему не навредит.

Например, есть метод из сторонней либы, который на вход принимает массив и выполняет расчеты. Доступа к исходникам нету. Мы запускаем в отдельном потоке выполнение и может так случится, что она не отработает за необходимое время. Что нам делать, так как? Получается, что единственный вариант — это прекратить работу убив поток. Или есть варианты по лучше?
И какова уверенность, что он не навредит? Утечки памяти и ресурсов это не вред? Кто знает, может там неуправляемый код есть.
А есть еще какие-то варианты, если исходный код либы не доступен => туда нельзя добавить проверку токенов отмены?

Вроде, отдельный домен решает эту проблему красиво и его не жалко прибить?
При выгрузке домена, под капотом происходит Abort всех потоков, находящихся в нём. Правда память в итоге очистится, так что утечки не страшны, но не уверен насчёт неуправляемых ресурсов, нужно почитать про это

В текущих условиях мне приходит в голову только вынос кода в отдельный процесс. Это относительно несложно делать на лету при помощи ExpressionTrees и пайпов.
А отдельный домен- это разве не полностью изолированная область => пофиг что там поломается при убийстве потоков?

Правда, утечки неуправляемых ресурсов все же возможны…
Отредактировал комментарий уже после вашего ответа :(

Вот что пишут:

Unloading the AppDomain will release any managed memory associated with it. This is, in fact, how ASP.NET works. The one catch is that unmanaged objects must be set up properly (the full Dispose pattern, for example), otherwise they'll keep it until the process is terminated.
А есть пример, как на лету создать процесс через ExpressionTrees?
Честно говоря, я сам не пробовал. Идея в том, что через ряд ухищрений их можно сериализовать и отправить в заранее заготовленный экзешник, в котором и исполнять в виде отдельного процесса.

Но в такой схеме гораздо проще использовать рефлексию: отправить в экзешник путь до либы, класс, метод и сериализованные параметры. Остается только на каждый запуск генерировать уникальное имя процесса и управлять его временем жизни. Результат возвращать так же в сериализованном виде

Я видел, как его дёргают через рефлексию ) Дичь, конечно, но проще ))

Это только в первых версиях .NET Core было возможно, начиная как минимум с 2.1 Thread.AbortInternal вырвали с корнями
Sign up to leave a comment.

Articles