Здравствуйте, Serginio1, Вы писали:
НС>>Это вероятностный момент. S> Что может сломаться вне блока try catch?
Если исключение вылетит в статическом конструкторе, то этот конструктор больше никогда не вызовется и люьбой код, завязанный на него не будет работать до смерти процесса.
Единственный нормальный способ дропнуть не умеющий отменяться код, как тут уже написали — запускать его в отдельном процессе и грохать процесс.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Это вероятностный момент. S>> Что может сломаться вне блока try catch?
НС>Если исключение вылетит в статическом конструкторе, то этот конструктор больше никогда не вызовется и люьбой код, завязанный на него не будет работать до смерти процесса. НС>Единственный нормальный способ дропнуть не умеющий отменяться код, как тут уже написали — запускать его в отдельном процессе и грохать процесс.
Слишком много связей. И случается это раз в пятилетку и пересоздать объект не проблема. Зависает скорее всего по
WaitHandle.WaitOne и по каким то причинам не дожидается сигнала, а основное приложение висит и годеныш еще и привязан к UI потоку (запуск потока с STA не помогал видно еще SynchronizationContext нужен был ).
И в большинстве своем это связано с тем, что функция должна вернуть false.
Проблем не было. Если бы были, то сделал бы отдельным доменом. Но и их в Core нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Все смеются надомной, но я то всего навсего прошу пример, как такую ситуацию разрулить причем в основном потоке
Сколько времени проходит между вызовом Thread.Abort и появлением ThreadAbortException? Может быть вы дергаете Thread.Abort, unmanaged функция спокойно завершается, управление возвращается в CLR и тут уже появляется исключение. Если это не так, то нужно какое-то объяснение как может Thread.Abort прервать выполнение unmanaged функции.
Здравствуйте, gusilebedi, Вы писали:
G>Здравствуйте, Serginio1, Вы писали:
S>> Все смеются надомной, но я то всего навсего прошу пример, как такую ситуацию разрулить причем в основном потоке
G>Сколько времени проходит между вызовом Thread.Abort и появлением ThreadAbortException? Может быть вы дергаете Thread.Abort, unmanaged функция спокойно завершается, управление возвращается в CLR и тут уже появляется исключение. Если это не так, то нужно какое-то объяснение как может Thread.Abort прервать выполнение unmanaged функции.
Секунд 15 жду. Ну у потока есть функция, можно и бросить исключение.
Функция то внутри может просто ожидать события по WaitOne.
У потока есть функция. Можно остановить поток и запихнуть в регистры код окончания функции.
Вариантов куча. try-catch (Справочник по C#)
Когда возникло исключение (еы можешь сам вызвать любое исключение для предотваращения кода), то код ниже исключения не выполняется и переходт в catch все тоже самое и Thread.Abort
Проблемы возникают если ты не обработал ThreadAbortException Thread.Abort Метод
При вызове этого метода в потоке система создает исключение ThreadAbortException в потоке, чтобы его прервать. ThreadAbortException — специальное исключение, которое может быть перехвачено кодом приложения, но повторно создается в конце catch блока, если ResetAbort не вызывается метод. ResetAbort отменяет запрос для прерывания и предотвращает ThreadAbortException завершение потока потоком. Невыполненные finally блоки выполняются до отмены потока.
Хотя там же пишут
Если Abort вызывается в управляемом потоке во время выполнения неуправляемого кода, ThreadAbortException исключение не создается, пока поток не вернется в управляемый код.
Unmanaged code is only abortable if it is an "alertable wait state". It won't be when it is burning 100% cpu cycles. P/Invoking TerminateThread would work, assuming you could obtain the thread handle, which .NET makes very difficult. It won't help anyway, you'll leak the thread stack. At one megabyte, you'll quickly run out of virtual memory. Even if this only an occasional need, you're still liable to run into major problems since the thread has mutated global program state and you don't know how to restore it.
The only good way to abort unmanaged code is to run it in a separate process and shoot it in the head with Process.Kill(). The operating system will clean up the shrapnel. You'll need to write a little hosting program for the DLL and use one of the process interop facilities to talk to it. Sockets, named pipes, .NET remoting, WCF, take your pick.
28
По русск
Неуправляемый код может быть прерван только в том случае, если он находится в "состоянии ожидания с возможностью оповещения".
У меня как раз такой случай
и солнце б утром не вставало, когда бы не было меня
Если поток во время выполнения нативной функции находится в Alertable Wait State, то значит он крутить цикл и ждет сообщений. Вы можете перед вызовом функции зарегистрировать обработчик и вызвать его через сколько-то секунд. Цикл, который крутится внутри нативной функции дернет ваш обработчик и дальше нужно придумать как стек размотать. Для этого должен быть какой-то стандартный способ. Возможно вернуть ошибку из обработчика или кинуть исключение.
Здравствуйте, gusilebedi, Вы писали:
G>Если поток во время выполнения нативной функции находится в Alertable Wait State, то значит он крутить цикл и ждет сообщений. Вы можете перед вызовом функции зарегистрировать обработчик и вызвать его через сколько-то секунд. Цикл, который крутится внутри нативной функции дернет ваш обработчик и дальше нужно придумать как стек размотать. Для этого должен быть какой-то стандартный способ. Возможно вернуть ошибку из обработчика или кинуть исключение.
Он не крутится, а скорее всего висит на мьютексе. Это системная функция я в неё залезть не могу.
Эта проблема возникает очень редко и Thread.Abort прекрасно справляется.
Я к тому, что есть случаи где Thread.Abort можно применять для нативного кода и при этом ничего не ломается.
А городить ради этого отдельные домены или процессы тоже не имеет особого смысла.
Только и всего. А так поверь я прекрасно понимаю проблемы с Thread.Abort. Но за многие годы в том коде, что работает их не было
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Только и всего. А так поверь я прекрасно понимаю проблемы с Thread.Abort. Но за многие годы в том коде, что работает их не было
Мне не раз доводилось ловить последствия брошенного исключения дотнетеым коллбэком, вызванным нативным кодом. Исключения бодро прилетают, но нативный код не знающий о исключениях — бодро схлопывается. Например был цикл сообщений — получите — теперь его нет. Разумеется ни о каком внятном продолжении речи не идет вообще.
Ну, а Thread.Abort своими руками сделать не велика проблема, вам же уже ж объяснили как это может работать. QueueUserAPC + throw. Но коллеги будут ругаться и бить ногами.
