namespace System.Threading
{
public sealed partial class Thread : CriticalFinalizerObject
{
// …
[Obsolete(Obsoletions.ThreadAbortMessage, DiagnosticId = Obsoletions.ThreadAbortDiagId, UrlFormat = Obsoletions.SharedUrlFormat)]
public void Abort()
{
throw new PlatformNotSupportedException(SR.PlatformNotSupported_ThreadAbort);
}
[Obsolete(Obsoletions.ThreadAbortMessage, DiagnosticId = Obsoletions.ThreadAbortDiagId, UrlFormat = Obsoletions.SharedUrlFormat)]
public void Abort(object? stateInfo)
{
throw new PlatformNotSupportedException(SR.PlatformNotSupported_ThreadAbort);
}
[Obsolete(Obsoletions.ThreadAbortMessage, DiagnosticId = Obsoletions.ThreadAbortDiagId, UrlFormat = Obsoletions.SharedUrlFormat)]
public static void ResetAbort()
{
throw new PlatformNotSupportedException(SR.PlatformNotSupported_ThreadAbort);
}
[Obsolete("Thread.Suspend has been deprecated. Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources. https://go.microsoft.com/fwlink/?linkid=14202", false)]
public void Suspend()
{
throw new PlatformNotSupportedException(SR.PlatformNotSupported_ThreadSuspend);
}
[Obsolete("Thread.Resume has been deprecated. Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources. https://go.microsoft.com/fwlink/?linkid=14202", false)]
public void Resume()
{
throw new PlatformNotSupportedException(SR.PlatformNotSupported_ThreadSuspend);
}
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, fdn721, Вы писали:
MA>>>Без Thread.Abort они теряют практический смысл.
F>>А использование Thread.Abort — это пример эталонного гавнокода.
_FR>И не напоминайте
У вас есть код, которому нужен именно Thread.Abort и нет возможности переписать с использованием CancellationToken или другого аналога ?
Всегда есть хардкор вариант DllImport TerminateThread, но зачем
Здравствуйте, _NN_, Вы писали:
MA>>>>Без Thread.Abort они теряют практический смысл. F>>>А использование Thread.Abort — это пример эталонного гавнокода. _FR>>И не напоминайте _NN>У вас есть код, которому нужен именно Thread.Abort и нет возможности переписать с использованием CancellationToken или другого аналога ?
Наоборот, я видел код с Thread::Abort() и предлагал исправить, но слышал в ответ, что раз такой метод есть, то странно им не пользоваться, тем более с ним всё так удобно.
И никакие отсылки к рекомендациям по [не-]использованию этого метода на собеседников не действовали.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Наоборот, я видел код с Thread::Abort() и предлагал исправить, но слышал в ответ, что раз такой метод есть, то странно им не пользоваться, тем более с ним всё так удобно. _FR>И никакие отсылки к рекомендациям по [не-]использованию этого метода на собеседников не действовали.
Подозреваю следующим этапом будут отмазки в стиле в .NET 5.0 нет Thread.Abort не будем на него переходить
Здравствуйте, _NN_, Вы писали:
_FR>>И не напоминайте _NN>У вас есть код, которому нужен именно Thread.Abort и нет возможности переписать с использованием CancellationToken или другого аналога ? _NN>Всегда есть хардкор вариант DllImport TerminateThread, но зачем
Для примера есть системный код который зависает по неизвестным причинам. При этом нет никакого async и CancellationToken. Можно по истечении времени кинуть Thread.Abort отловить его и сделать Thread.ResetAbort
Во всяком случае можно дальше работать или отвиснуть поток, что бы не копились
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Для примера есть системный код который зависает по неизвестным причинам. При этом нет никакого async и CancellationToken. Можно по истечении времени кинуть Thread.Abort отловить его и сделать Thread.ResetAbort S>Во всяком случае можно дальше работать или отвиснуть поток, что бы не копились
Если "системный код" — это неуправляемый код, то Thread.Abort тут ничем не поможет, т.к. Thread.Abort реализован средствами CLR (соотв. никак не связан с TerminateThread) — проставляется спец. флаг что требуется Abort, который в определенных, хз каких, местах исполняемого кода проверяется, известно только где не проверяется (catch, finnaly, CER, неуправляемый код, может где еще). По этому флагу и генерится исключение ThreadAbortException, который можно перехватить и да, сбросить его (ResetAbort).
Здравствуйте, pilgrim_, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Для примера есть системный код который зависает по неизвестным причинам. При этом нет никакого async и CancellationToken. Можно по истечении времени кинуть Thread.Abort отловить его и сделать Thread.ResetAbort S>>Во всяком случае можно дальше работать или отвиснуть поток, что бы не копились
_>Если "системный код" — это неуправляемый код, то Thread.Abort тут ничем не поможет, т.к. Thread.Abort реализован средствами CLR (соотв. никак не связан с TerminateThread) — проставляется спец. флаг что требуется Abort, который в определенных, хз каких, местах исполняемого кода проверяется, известно только где не проверяется (catch, finnaly, CER, неуправляемый код, может где еще). По этому флагу и генерится исключение ThreadAbortException, который можно перехватить и да, сбросить его (ResetAbort).
Как это не поможет. Есть два пути
1. В основном коде вызываем в try catch и запускаем наблюдающий поток и если завис бросаем Thread.Abort
2. Запускаем отдельный поток в котором в блоке try catch вызывается проблемная функция и через таймаут бросаем Thread.Abort.
Реально Thread.Abort в связке Thread.ResetAbort работает и в основном потоке. Практика!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Если "системный код" — это неуправляемый код, то Thread.Abort тут ничем не поможет, т.к. Thread.Abort реализован средствами CLR (соотв. никак не связан с TerminateThread) — проставляется спец. флаг что требуется Abort, который в определенных, хз каких, местах исполняемого кода проверяется, известно только где не проверяется (catch, finnaly, CER, неуправляемый код, может где еще). По этому флагу и генерится исключение ThreadAbortException, который можно перехватить и да, сбросить его (ResetAbort).
S> Как это не поможет. Есть два пути
Выделил для тебя
S>1. В основном коде вызываем в try catch и запускаем наблюдающий поток и если завис бросаем Thread.Abort S>2. Запускаем отдельный поток в котором в блоке try catch вызывается проблемная функция и через таймаут бросаем Thread.Abort.
S> Реально Thread.Abort в связке Thread.ResetAbort работает и в основном потоке. Практика!
Путано излагаешь, неважно откуда был вызван Thread.Abort, важно что прервать Abort можно только в прерываемом потоке с пом. перехвата ThreadAbortException и вызова Thread.ResetAbort.
Здравствуйте, pilgrim_, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Если "системный код" — это неуправляемый код, то Thread.Abort тут ничем не поможет, т.к. Thread.Abort реализован средствами CLR (соотв. никак не связан с TerminateThread) — проставляется спец. флаг что требуется Abort, который в определенных, хз каких, местах исполняемого кода проверяется, известно только где не проверяется (catch, finnaly, CER, неуправляемый код, может где еще). По этому флагу и генерится исключение ThreadAbortException, который можно перехватить и да, сбросить его (ResetAbort).
S>> Как это не поможет. Есть два пути
_>Выделил для тебя
Из практики например системный код это COM привязанный к основному потоку приложения. И наверняка не управляемый.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_FR>>>И не напоминайте _NN>>У вас есть код, которому нужен именно Thread.Abort и нет возможности переписать с использованием CancellationToken или другого аналога ? _NN>>Всегда есть хардкор вариант DllImport TerminateThread, но зачем
S>Для примера есть системный код который зависает по неизвестным причинам. При этом нет никакого async и CancellationToken. Можно по истечении времени кинуть Thread.Abort отловить его и сделать Thread.ResetAbort S>Во всяком случае можно дальше работать или отвиснуть поток, что бы не копились
Это не поможет разве что управление потом возвращается в управляемый код, а там уже и CancellationToken можно поставить.
If Abort is called on a managed thread while it is executing unmanaged code, a ThreadAbortException is not thrown until the thread returns to managed code.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, _NN_, Вы писали:
_FR>>>>И не напоминайте _NN>>>У вас есть код, которому нужен именно Thread.Abort и нет возможности переписать с использованием CancellationToken или другого аналога ? _NN>>>Всегда есть хардкор вариант DllImport TerminateThread, но зачем
S>>Для примера есть системный код который зависает по неизвестным причинам. При этом нет никакого async и CancellationToken. Можно по истечении времени кинуть Thread.Abort отловить его и сделать Thread.ResetAbort S>>Во всяком случае можно дальше работать или отвиснуть поток, что бы не копились
_NN>Это не поможет разве что управление потом возвращается в управляемый код, а там уже и CancellationToken можно поставить. _NN>
_NN>If Abort is called on a managed thread while it is executing unmanaged code, a ThreadAbortException is not thrown until the thread returns to managed code.
Управление всеми потоками осуществляется посредством класса Thread , включая потоки, созданные средой CLR или созданные за пределами среды выполнения и входящие в управляемую среду для выполнения кода. Среда выполнения отслеживает в своем процессе все потоки, которые когда-либо выполняли код в управляемой среде. Другие потоки она не отслеживает. Потоки могут входить в управляемую среду выполнения посредством COM-взаимодействия (так как среда выполнения предоставляет управляемые объекты неуправляемой среде в качестве COM-объектов), функции COM DllGetClassObject и вызова неуправляемого кода.
Когда неуправляемый поток входит в среду выполнения, например, посредством вызываемой оболочки COM, система проверяет локальное хранилище потока данного потока для поиска внутреннего управляемого объекта Thread . Если он найден, среда выполнения уже оповещена об этом потоке. Если найти объект не удается, среда выполнения создает новый объект Thread и устанавливает его в локальном хранилище потока данного потока.
В следующей таблице элементы потоков Win32 сопоставляются со своими ближайшими аналогами из среды выполнения. Обратите внимание, что такое сопоставление не означает идентичную функциональность. Например, TerminateThread не выполняет предложения finally , не освобождает ресурсы и не может быть запрещен. Однако Thread.Abort выполняет весь ваш код отката, освобождает все ресурсы и может быть отменен с помощью ResetAbort. Прежде чем делать предположения о функциональности, тщательно изучите документацию.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_NN>>Это не поможет разве что управление потом возвращается в управляемый код, а там уже и CancellationToken можно поставить. _NN>>
_NN>>If Abort is called on a managed thread while it is executing unmanaged code, a ThreadAbortException is not thrown until the thread returns to managed code.
_>Тов. Сергей, каким образом во вашему мнению неуправляемый код может узнать что был вызван какой-то там "Thread.Abort"?
Неуправляемый не знает, но Thread.Abort прерывает работу потока и вызывает ThreadAbortException
Что там внутри честно не знаю, но это факт.
Мне просто нужно прервать выполнение зависшей неуправляемой функцию по таймауту
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, pilgrim_, Вы писали:
_>>Тов. Сергей, каким образом во вашему мнению неуправляемый код может узнать что был вызван какой-то там "Thread.Abort"? S> Неуправляемый не знает, но Thread.Abort прерывает работу потока и вызывает ThreadAbortException S>Что там внутри честно не знаю, но это факт. S> Мне просто нужно прервать выполнение зависшей неуправляемой функцию по таймауту
Ну вот и подумай, остановить ты можешь только managed поток, поставь там проверку на cancellationtoken и все дальше будет работать. Я интуитивно никогда Thread.Abort не пользовался. Это тот случай когда нужно пару раз подумать нужны ли его сайд эффекты из-за того что в свое время поленились поставить проверки.
Здравствуйте, Serginio1, Вы писали: S>Что там внутри честно не знаю, но это факт. S> Мне просто нужно прервать выполнение зависшей неуправляемой функцию по таймауту
Ваш код работает не так, как вы думаете. Точнее, не работает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
D>Ну вот и подумай, остановить ты можешь только managed поток, поставь там проверку на cancellationtoken и все дальше будет работать. Я интуитивно никогда Thread.Abort не пользовался. Это тот случай когда нужно пару раз подумать нужны ли его сайд эффекты из-за того что в свое время поленились поставить проверки.
Научи. Есть неуправляемая функция в основном UI потоке которая зависает.
cancellationtoken например в .Net 3.5 нет
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>>Что там внутри честно не знаю, но это факт. S>> Мне просто нужно прервать выполнение зависшей неуправляемой функцию по таймауту S>Ваш код работает не так, как вы думаете. Точнее, не работает.
То есть мой код продолжает работать, вместо того что бы намертво зависнуть.
Ну не получилось выполнить и хрен с ним.
Что неправильно работает?
Код такого плана
Мой код такого плана https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.threadabortexception?view=net-5.0
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Ну вот и подумай, остановить ты можешь только managed поток, поставь там проверку на cancellationtoken и все дальше будет работать. Я интуитивно никогда Thread.Abort не пользовался. Это тот случай когда нужно пару раз подумать нужны ли его сайд эффекты из-за того что в свое время поленились поставить проверки.
S>Научи. Есть неуправляемая функция в основном UI потоке которая зависает. S>cancellationtoken например в .Net 3.5 нет
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Ну вот и подумай, остановить ты можешь только managed поток, поставь там проверку на cancellationtoken и все дальше будет работать. Я интуитивно никогда Thread.Abort не пользовался. Это тот случай когда нужно пару раз подумать нужны ли его сайд эффекты из-за того что в свое время поленились поставить проверки.
S>Научи. Есть неуправляемая функция в основном UI потоке которая зависает. S>cancellationtoken например в .Net 3.5 нет
Опять же у вас неуправляемая функция. Thread.Abort в неуправляемой функции не вызовится никогда, .NET не знает на чем там сейчас крутится функция, может на диск пишет или память освобождает. Он сработает как только когды вы из нее выйдете и попадете в управляемую среду — нафига тогда этот Abort?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, Danchik, Вы писали:
D>>>Ну вот и подумай, остановить ты можешь только managed поток, поставь там проверку на cancellationtoken и все дальше будет работать. Я интуитивно никогда Thread.Abort не пользовался. Это тот случай когда нужно пару раз подумать нужны ли его сайд эффекты из-за того что в свое время поленились поставить проверки.
S>>Научи. Есть неуправляемая функция в основном UI потоке которая зависает. S>>cancellationtoken например в .Net 3.5 нет
_NN>Можете не благодарить https://www.nuget.org/packages/TaskParallelLibrary/
Спасибо! _NN>Другой вопрос почему мы говорим о .NET 3.5 когда есть .NET Core , который прекрасно работает на Windows 7.
Например xp еще есть у клиентов. Ну опять же куда мне cancellationtoken прикрутить к основному потоку?
И где мне вызвать Cancel(); если функция зависла?
Мне бы примерчик, как прервать неуправляемую функцию которая привязана к UI потоку?
и солнце б утром не вставало, когда бы не было меня
S>> Покажи код. Буду благодарен
S>>Мой код такого плана https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.threadabortexception?view=net-5.0
D>Опять же у вас неуправляемая функция. Thread.Abort в неуправляемой функции не вызовится никогда, .NET не знает на чем там сейчас крутится функция, может на диск пишет или память освобождает. Он сработает как только когды вы из нее выйдете и попадете в управляемую среду — нафига тогда этот Abort?
А мне не надо перехватывать в неуправляемой функции.
Мне нужно прервать выполнение этой функции в управляемом основном потоке по таймауту.
и солнце б утром не вставало, когда бы не было меня
Везде в примерах нужно опросить CancellationToken на ct.IsCancellationRequested
Либо вызвать CancellationTokenSource Cancel для установи исключения.
Как эти мне снять выполнение зависшей функции.
Я уже у всех прошу решения. Никто так и не показал
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Везде в примерах нужно опросить CancellationToken на ct.IsCancellationRequested S>Либо вызвать CancellationTokenSource Cancel для установи исключения. S> Как эти мне снять выполнение зависшей функции. S> Я уже у всех прошу решения. Никто так и не показал
Автоматически как в случае с Thread.Abort думаю нет способа.
Надо посмотреть как в .NET Framework реализовано и что происходить в .NET Core в этом же месте.
Самый надёжный вариант это вручную проставлять все места возврата из неуправляемого кода.
Полагаю этого хочется и избежать.
В принципе можно динамически или статически сгенерировать обёртку для COM интерфейса которая будет проверять CancellationToken после каждого вызова и кидать исключение об отмене.
Здравствуйте, Serginio1, Вы писали: S> То есть мой код продолжает работать, вместо того что бы намертво зависнуть. S>Ну не получилось выполнить и хрен с ним. S>Что неправильно работает?
Вы думаете, что прерываете вызов во время неуправляемого кода. А на самом деле нет. То, что ваш код не зависает намертво — случайность. S>Код такого плана S>Мой код такого плана https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.threadabortexception?view=net-5.0
Перепишите его.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
public static void DoWork() {
try {
callUnmagedCode(); // вот этот код зависает причем в основном потоке
}
}
catch(ThreadAbortException e) {
Thread.ResetAbort();
}
}
Тут кода то с гулькин ..
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Петрухин Эдуард, Вы писали:
ПЭ>Здравствуйте, Serginio1, Вы писали:
S>> Мне бы примерчик, как прервать неуправляемую функцию которая привязана к UI потоку?
ПЭ>Может быть, вот эта статья поможет: Задачи и отмена в .Net — tips & tricks.
Спасибо! Это я все читал давным давно.
Мне примерчик. Сейчас типа такого
public static void DoWork() {
try {
callUnmagedCode(); // вот этот код зависает причем в основном потоке
}
}
catch(ThreadAbortException e) {
Thread.ResetAbort();
}
}
Все смеются надомной, но я то всего навсего прошу пример, как такую ситуацию разрулить причем в основном потоке
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> И как мне с его помощью прервать выполнение неуправляемой функции в основном потоке?
Никак. Ровно как и в случае Thread.Abort.
S> Я уже у всех прошу решения. Никто так и не показал
Дотнет так устроен, что безопасно отменить работу произвольной функции без поддержки этого в самой функции нельзя из-за особенности работы статических конструкторов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>> И как мне с его помощью прервать выполнение неуправляемой функции в основном потоке?
НС>Никак. Ровно как и в случае Thread.Abort.
S>> Я уже у всех прошу решения. Никто так и не показал
НС>Дотнет так устроен, что безопасно отменить работу произвольной функции без поддержки этого в самой функции нельзя из-за особенности работы статических конструкторов.
Мне не интересно безоапасно. Мне нужно прервать зависшую функцию или перезапустить приложение (если надо сериализовать данные), а не грохать полностью приложение через диспетчер задач
Thread.Abort позволяет это сделать, а вот всякие CancellationToken нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
НС>>Дотнет так устроен, что безопасно отменить работу произвольной функции без поддержки этого в самой функции нельзя из-за особенности работы статических конструкторов. S> Мне не интересно безоапасно. Мне нужно прервать зависшую функцию
И пофик что остальное приложение сломается?
S> или перезапустить приложение
Ну так перезапускай. Process.Exit никто не отменял.
S>public static void DoWork() {
S> try {
S> callUnmagedCode(); // вот этот код зависает причем в основном потоке
S> }
S> }
S> catch(ThreadAbortException e) {
S> Thread.ResetAbort();
S> }
S> }
S>
S>Тут кода то с гулькин ..
Такие дела делаются внешиними процесами. Стартуется еще один EXE с параметрами, на выход он должен дать результат. Если процес не завершил работу вовремя — прибиваем его. Только так вы не угробите свое рабочее приложение.
Также можно стартануть такой процес как RPC сервер, чтобы не плодить параметров. И рестартовать его когда надо.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Дотнет так устроен, что безопасно отменить работу произвольной функции без поддержки этого в самой функции нельзя из-за особенности работы статических конструкторов. S>> Мне не интересно безоапасно. Мне нужно прервать зависшую функцию
НС>И пофик что остальное приложение сломается?
Оно не ломается. S>> или перезапустить приложение
НС>Ну так перезапускай. Process.Exit никто не отменял.
А сохранить данные? Память то не ломается. Ломается то, что в блоке try catch
Пересоздам все что нужно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Danchik, Вы писали: S>>Тут кода то с гулькин ..
D>Такие дела делаются внешиними процесами. Стартуется еще один EXE с параметрами, на выход он должен дать результат. Если процес не завершил работу вовремя — прибиваем его. Только так вы не угробите свое рабочее приложение.
D>Также можно стартануть такой процес как RPC сервер, чтобы не плодить параметров. И рестартовать его когда надо.
Значит примера не будет. Ну то есть отдельный процесс плодить. Доменов то в Core тоже нет.
Еще раз ломается то, что находится в try catch. А его легко восстановить.
Да и трудоемко выводить весь код а отдельный процесс, когда куча взаимосвязей. И это проблема возникает раз в пятилетку
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>И пофик что остальное приложение сломается? S>> Оно не ломается.
НС>Это вероятностный момент.
Что может сломаться вне блока try catch?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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. Но коллеги будут ругаться и бить ногами.
