Как успешно завершить процесс с

Функция exit

Функция exit выполняет немедленное завершение программы. Завершаемый процесс, как правило, выполняет очистку используемой памяти. Во-вторых, все функции, зарегистрированные вызовами atexit , выполняются в порядке, обратном порядку их регистрации. В таком случае, все используемые программой потоки закрываются, и временные файлы удаляются, и, наконец, управление возвращается ОС или другой программе.

Аргумент параметра value возвращается принимающей стороной (ОС или другой программой).

Как правильно остановить Task?

GooliveR's user avatar

Вы не можете остановить бегущий таск точно так же, как вы не можете остановить бегущий thread. Вы можете лишь попросить таск остановиться, и надеяться, что он послушает вашу просьбу.

Если метод OutHookProc.prockill под вашим контролем, поменяйте его сигнатуру так, чтобы он принимал ещё и CancellationToken , передавайте токен ещё и туда, и в методе время от времени проверяйте токен и прекращайтесь работу, если токен запрашивает это. Если вы внутри OutHookProc.prockill вызываете другие асинхронные методы, передавайте им токен тоже.

Если метод не под вашим контролем и не предоставляет средств для остановки, остановить его никак нельзя. Единственное, что можно сделать — это проигнорировать результат выполнения таска, но при этом он продолжит бежать в фоне.

Завершить процесс

Как завершить процесс зная его имя?
Хочу убить процесс зная его имя, но, он не убивается. (( Как это можно сделать? Пишу на.

как завершить процесс запущенный от себя по имени процесса?
как завершить процесс запущенный от себя по имени процесса? что то искал везде но не нашёл .

Открыть процесс процесс на полный доступ, и запретить для других
Всем доброго времени суток. Друзья, HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE.

Завершить программу
Вот это уже есть, помогите доделать А) При введении недопустимого символа в поля ввода значений.

Задачи и отмена в .Net — tips & tricks

В этом примере код в функциях Start и Cancel — внешний слой. Он инициирует выполнение асинхронной операции вызовом метода Task.Run . При этом он передаёт CancellationToken сразу в два места: во внутренний слой, непосредственно выполняющий операцию (метод SomeWork ) и в инфраструктурный слой (второй аргумент функции Task.Run ). Функция Cancel запрашивает отмену операции.

Внутренний слой (функция SomeWork ) помимо выполнения полезной нагрузки периодически проверяет, не запрошена ли отмена и, если надо, генерирует исключение OperationCanceledException , сигнализирующее о том, что запрос на отмену был обработан.

Инфраструктурный слой (внутри TPL) для поддержки отмены делает две вещи. Во-первых, перед запуском переданной в Task.Run функции проверяет, не запрошена ли отмена. Если да, то функция даже не запускается на выполнение. Во-вторых, специальным образом обрабатывает исключение OperationCanceledException , сообщающее об отмене операции.

Обработка запроса на отмену

После вызова метода CancellationTokenSource.Cancel (или по истечении таймаута, заданного при вызове конструктора CancellationTokenSource /метода CancellationTokenSource.CancelAfter ) объект CancellationTokenSource переходит в отменённое состояние. Переход в отменённое состояние может произойти ровно один раз. Передумать и сделать отменённый CancellationTokenSource неотменённым невозможно, а повторные вызовы Cancel игнорируются.

При переходе в отменённое состояние вызываются callback-функции, зарегистрированные через метод CancellationToken.Register , свойство CancellationToken.IsCancellationRequested начинает возвращать true , а вызов метода CancellationToken.ThrowIfCancellationRequested будет генерировать исключение OperationCanceledException .

Код внутреннего слоя должен периодически проверять наличие запроса на отмену. Как правило, код проверки сводится к вызову метода ThrowIfCancellationRequested , если операция может быть прервана сразу. Если перед завершением работы нужно выполнить дополнительные действия (например, освободить используемые ресурсы), то код проверки обращается к свойству IsCancellationRequested . Если оно равно true , выполняется очистка ресурсов и генерируется исключение OperationCanceledException (опять же вызовом метода ThrowIfCancellationRequested или вручную).

Здесь важно обратить внимание на следующее. Во-первых, если запрос на отмену не будет обработан кодом операции, операция продолжит выполняться. В конце концов, когда операция завершится (штатно или с исключением), задача станет завершённой ( Task.IsCompleted == true ), но она не будет считаться отменённой ( Task.IsCanceled == false ).

Во-вторых, нужно подобрать оптимальный размер интервала между проверками. Если интервал будет слишком большой, операция будет выполнять лишнюю работу в случае отмены. Если интервал будет слишком маленький — накладные расходы на проверку увеличат время выполнения операции. Какие-то конкретные значения порекомендовать сложно, многое зависит от конкретного сценария. Общие рекомендации такие: если вероятность отмены не очень велика, проверки можно выполнять реже. Если отмена операции инициируется пользователем, для обеспечения отзывчивости UI достаточно выполнять проверку каждые 200-250 мс. Если операция выполняется в серверном приложении, проверки стоит выполнять чаще, чтобы в случае отмены не тратить впустую ресурсы сервера. Проверки не должны занимать больше нескольких процентов от общего времени выполнения операции. Опять же, повторюсь, что это всего лишь общие рекомендации и в каждом конкретном случае разработчик должен сам принимать решение с учётом всех влияющих факторов. Возможно, не лишней окажется помощь профилировщика.

В-третьих, у CancellationToken есть свойство CanBeCanceled . Если оно возвращает false , то запроса на отмену гарантированно не будет и проверки можно не выполнять. CanBeCanceled равно false , если CancellationToken получен с помощью статического свойства CancellationToken.None или создан конструктором по умолчанию или конструктором с параметром, равным false .

  • Код асинхронной операции должен сгенерировать исключение OperationCanceledException , в конструктор которого должен быть передан CancellationToken .
  • Тот же самый CancellationToken должен передаваться в метод, который создаёт и запускает задачу.
  • Свойство IsCancellationRequested у CancellationToken должно возвращать true .

Здесь в конструктор OperationCanceledException не передаётся CancellationToken . Именно поэтому предпочтительно использовать метод CancellationToken.ThrowIfCancelationRequested , а не генерировать OperationCanceledException вручную.

В этом примере при создании задачи в метод Task.Run не был передан CancellationToken .

Здесь для создания задачи и для отмены используются CancellationToken ’ы, полученные из разных CancellationTokenSource ’ов.

Тут генерируется OperationCanceledException , хотя отмена запрошена не была.

Во всех примерах исключение OperationCanceledException будет обработано внутри TPL не как сигнал об отмене, а как обычное исключение. В результате задача завершится не с отменой, а с ошибкой ( Task.IsCancelled == false , Task.IsFaulted == true ).

Отмена и задачи-продолжения

TPL позволяет с помощью перегруженного метода Task.ContinueWith объединять задачи в цепочки. Задача, созданная методом Task.ContinueWith , называется задачей-продолжением, а задача, у которой вызывался метод — задачей-предшественником. Задача-продолжение ожидает завершения задачи-предшественника, после чего выполняется:

Задачи-продолжения в полной мере поддерживают отмену и все, что было написано выше, применимо и к ним. У метода Task.ContinueWith есть перегрузки, позволяющие связать с создаваемой задачей CancellationToken .

Если запрос на отмену придет, когда задача-продолжение ещё не начала выполняться, она выполняться не будет. При этом, по умолчанию, задача-продолжение отменится сразу и может завершиться раньше, чем задача-предшественник:

Но такое поведение можно изменить, если при создании задачи-продолжения с помощью флага TaskContinuationOptions.LazyCancellation указать, что требуется «ленивая» отмена. В этом случае задача-продолжение не отменится (и не завершится), пока не завершится задача-предшественник:

Отдельный интерес представляет случай, когда задача-продолжение может стать отменённой без использования CancellationToken . В TaskContinuationOptions есть ряд флагов, которые позволяют указать, в каких случаях задача-продолжение должна запускаться. Например, для задачи-предшественника можно создать две задачи-продолжения — одну на случай, когда задача-предшественник выполнится нормально, вторую — на случай, когда в задаче-предшественнике произойдёт ошибка/отмена. После завершения задачи-предшественника запустится только одна из задач-продолжений, а вторая станет отменённой:

Отмена и async-методы

В C# 5.0 появились async-методы. С точки зрения отмены async-методы интересны тем, что в качестве возвращаемого значения могут использовать только void и типы Task / Task. Причём в случае, когда async-метод возвращает задачу (Task /
может быть переписан с помощью async-методов следующим образом:

Обратите внимание, в коде нет никаких Task.Run , ни Task.Factory.StartNew , ничего такого. Метод SomeWork возвращает значение типа int . Компилятор сам генерирует код, который заворачивает тело SomeWork в
и

  • Даже если отмена была запрошена до вызова async-метода, тело async-метода всё равно будет выполняться. В случае с ручным созданием задачи (например, через Task.Run или Task.ContinueWith ) это не так. Именно поэтому в примере присутствуют проверки 1 и 2.
  • Исключения, возникшие внутри async-метода, обрабатываются сгенерированным компилятором кодом. OperationCanceledException считается отменой операции. При этом CancellationToken , переданный в конструктор исключения ни с чем не сравнивается, т.к. сравнивать его не с чем. Более того, для отмены достаточен сам факт исключения нужного типа, а наличие CancellationToken и его состояние никак не анализируется. Поэтому, в отличие от того же Task.Run , любой из нижеперечисленных способов приведёт к отмене:
Обработка отменённых задач

После завершения задачи свойство Task.IsCompleted начинает возвращать значение true . Завершится задача может штатно ( Task.Status == TaskStatus.RanToCompletion ), с ошибкой ( Task.Status == TaskStatus.Faulted ; Task.IsFaulted == true ) или с отменой ( Task.Status == TaskStatus.Canceled ; Task.IsCanceled == true ). С помощью этих свойств можно определить завершилась ли задача и как она завершилась.

Обработать завершённую задачу можно с помощью задач-продолжений. При этом удобно пользоваться флагами TaskContinuationOptions и создавать задачу-продолжение на каждый вариант завершения задачи-предшественника:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *