Cancelar uma tarefa pendente de forma síncrona no encadeamento da interface do usuário
Às vezes, depois de solicitar o cancelamento de uma tarefa pendente comCancellationTokenSource.CancelEu preciso ter certezaa tarefa atingiu corretamente o estado cancelado, antes que eu possa continuar. Na maioria das vezes, enfrento essa situação quando o aplicativo está sendo encerrado e quero cancelar todas as tarefas pendentes normalmente. No entanto, também pode ser um requisito da especificação do fluxo de trabalho da interface do usuário, quando o novo processo em segundo plano só pode ser iniciado se o processo pendente atual tiver sido totalmente cancelado ou atingido seu fim naturalmente.
Eu apreciaria se alguém compartilha sua abordagem ao lidar com esta situação. Estou falando do seguinte padrão:
_cancellationTokenSource.Cancel();
_task.Wait();
Como é, sabe-se que é capaz de causar facilmente um conflito quando usado no encadeamento da interface do usuário. No entanto, nem sempre é possível usar uma espera assíncrona (ou seja,await task; por exemplo.,aqui é um dos casos em queé possível). Ao mesmo tempo, é um cheiro de código simplesmente solicitar o cancelamento e continuar sem realmente observar seu estado.
Como um exemplo simples que ilustra o problema, posso ter certeza de que o seguinteDoWorkAsync tarefa foi totalmente cancelada dentroFormClosing manipulador de eventos. Se eu não esperar pelo_task dentroMainForm_FormClosing, Eu posso nem ver o"Finished work item N" rastreio para o item de trabalho atual, pois o aplicativo termina no meio de uma subtarefa pendente (que é executada em um encadeamento de pool). Se eu esperar, isso resulta em um impasse:
public partial class MainForm : Form
{
CancellationTokenSource _cts;
Task _task;
// Form Load event
void MainForm_Load(object sender, EventArgs e)
{
_cts = new CancellationTokenSource();
_task = DoWorkAsync(_cts.Token);
}
// Form Closing event
void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
_cts.Cancel();
try
{
// if we don't wait here,
// we may not see "Finished work item N" for the current item,
// if we do wait, we'll have a deadlock
_task.Wait();
}
catch (Exception ex)
{
if (ex is AggregateException)
ex = ex.InnerException;
if (!(ex is OperationCanceledException))
throw;
}
MessageBox.Show("Task cancelled");
}
// async work
async Task DoWorkAsync(CancellationToken ct)
{
var i = 0;
while (true)
{
ct.ThrowIfCancellationRequested();
var item = i++;
await Task.Run(() =>
{
Debug.Print("Starting work item " + item);
// use Sleep as a mock for some atomic operation which cannot be cancelled
Thread.Sleep(1000);
Debug.Print("Finished work item " + item);
}, ct);
}
}
}
Isso acontece porque o loop de mensagens do encadeamento da interface do usuário precisa continuar bombeando mensagens; portanto, a continuação assíncrona dentroDoWorkAsync (programado no diretórioWindowsFormsSynchronizationContext) tem a chance de ser executado e, eventualmente, atingiu o estado cancelado. No entanto, a bomba está bloqueada com_task.Wait(), o que leva ao impasse. Este exemplo é específico para WinForms, mas o problema também é relevante no contexto do WPF.
Nesse caso, não vejo outras soluções a não ser organizar um loop de mensagens aninhadas, enquanto aguardo o_task. De uma maneira distante, é semelhante aThread.Join, que continua enviando mensagens enquanto aguarda o término de um encadeamento. A estrutura não parece oferecer uma API de tarefa explícita para isso, então, eventualmente, criei a seguinte implementação deWaitWithDoEvents:
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
namespace WinformsApp
{
public partial class MainForm : Form
{
CancellationTokenSource _cts;
Task _task;
// Form Load event
void MainForm_Load(object sender, EventArgs e)
{
_cts = new CancellationTokenSource();
_task = DoWorkAsync(_cts.Token);
}
// Form Closing event
void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
// disable the UI
var wasEnabled = this.Enabled; this.Enabled = false;
try
{
// request cancellation
_cts.Cancel();
// wait while pumping messages
_task.AsWaitHandle().WaitWithDoEvents();
}
catch (Exception ex)
{
if (ex is AggregateException)
ex = ex.InnerException;
if (!(ex is OperationCanceledException))
throw;
}
finally
{
// enable the UI
this.Enabled = wasEnabled;
}
MessageBox.Show("Task cancelled");
}
// async work
async Task DoWorkAsync(CancellationToken ct)
{
var i = 0;
while (true)
{
ct.ThrowIfCancellationRequested();
var item = i++;
await Task.Run(() =>
{
Debug.Print("Starting work item " + item);
// use Sleep as a mock for some atomic operation which cannot be cancelled
Thread.Sleep(1000);
Debug.Print("Finished work item " + item);
}, ct);
}
}
public MainForm()
{
InitializeComponent();
this.FormClosing += MainForm_FormClosing;
this.Load += MainForm_Load;
}
}
/// <summary>
/// WaitHandle and Task extensions
/// by Noseratio - https://stackoverflow.com/users/1768303/noseratio
/// </summary>
public static class WaitExt
{
/// <summary>
/// Wait for a handle and pump messages with DoEvents
/// </summary>
public static bool WaitWithDoEvents(this WaitHandle handle, CancellationToken token, int timeout)
{
if (SynchronizationContext.Current as System.Windows.Forms.WindowsFormsSynchronizationContext == null)
{
// https://stackoverflow.com/a/19555959
throw new ApplicationException("Internal error: WaitWithDoEvents must be called on a thread with WindowsFormsSynchronizationContext.");
}
const uint EVENT_MASK = Win32.QS_ALLINPUT;
IntPtr[] handles = { handle.SafeWaitHandle.DangerousGetHandle() };
// track timeout if not infinite
Func<bool> hasTimedOut = () => false;
int remainingTimeout = timeout;
if (timeout != Timeout.Infinite)
{
int startTick = Environment.TickCount;
hasTimedOut = () =>
{
// Environment.TickCount wraps correctly even if runs continuously
int lapse = Environment.TickCount - startTick;
remainingTimeout = Math.Max(timeout - lapse, 0);
return remainingTimeout <= 0;
};
}
// pump messages
while (true)
{
// throw if cancellation requested from outside
token.ThrowIfCancellationRequested();
// do an instant check
if (handle.WaitOne(0))
return true;
// pump the pending message
System.Windows.Forms.Application.DoEvents();
// check if timed out
if (hasTimedOut())
return false;
// the queue status high word is non-zero if a Windows message is still in the queue
if ((Win32.GetQueueStatus(EVENT_MASK) >> 16) != 0)
continue;
// the message queue is empty, raise Idle event
System.Windows.Forms.Application.RaiseIdle(EventArgs.Empty);
if (hasTimedOut())
return false;
// wait for either a Windows message or the handle
// MWMO_INPUTAVAILABLE also observes messages already seen (e.g. with PeekMessage) but not removed from the queue
var result = Win32.MsgWaitForMultipleObjectsEx(1, handles, (uint)remainingTimeout, EVENT_MASK, Win32.MWMO_INPUTAVAILABLE);
if (result == Win32.WAIT_OBJECT_0 || result == Win32.WAIT_ABANDONED_0)
return true; // handle signalled
if (result == Win32.WAIT_TIMEOUT)
return false; // timed out
if (result == Win32.WAIT_OBJECT_0 + 1) // an input/message pending
continue;
// unexpected result
throw new InvalidOperationException();
}
}
public static bool WaitWithDoEvents(this WaitHandle handle, int timeout)
{
return WaitWithDoEvents(handle, CancellationToken.None, timeout);
}
public static bool WaitWithDoEvents(this WaitHandle handle)
{
return WaitWithDoEvents(handle, CancellationToken.None, Timeout.Infinite);
}
public static WaitHandle AsWaitHandle(this Task task)
{
return ((IAsyncResult)task).AsyncWaitHandle;
}
/// <summary>
/// Win32 interop declarations
/// </summary>
public static class Win32
{
[DllImport("user32.dll")]
public static extern uint GetQueueStatus(uint flags);
[DllImport("user32.dll", SetLastError = true)]
public static extern uint MsgWaitForMultipleObjectsEx(
uint nCount, IntPtr[] pHandles, uint dwMilliseconds, uint dwWakeMask, uint dwFlags);
public const uint QS_KEY = 0x0001;
public const uint QS_MOUSEMOVE = 0x0002;
public const uint QS_MOUSEBUTTON = 0x0004;
public const uint QS_POSTMESSAGE = 0x0008;
public const uint QS_TIMER = 0x0010;
public const uint QS_PAINT = 0x0020;
public const uint QS_SENDMESSAGE = 0x0040;
public const uint QS_HOTKEY = 0x0080;
public const uint QS_ALLPOSTMESSAGE = 0x0100;
public const uint QS_RAWINPUT = 0x0400;
public const uint QS_MOUSE = (QS_MOUSEMOVE | QS_MOUSEBUTTON);
public const uint QS_INPUT = (QS_MOUSE | QS_KEY | QS_RAWINPUT);
public const uint QS_ALLEVENTS = (QS_INPUT | QS_POSTMESSAGE | QS_TIMER | QS_PAINT | QS_HOTKEY);
public const uint QS_ALLINPUT = (QS_INPUT | QS_POSTMESSAGE | QS_TIMER | QS_PAINT | QS_HOTKEY | QS_SENDMESSAGE);
public const uint MWMO_INPUTAVAILABLE = 0x0004;
public const uint WAIT_TIMEOUT = 0x00000102;
public const uint WAIT_FAILED = 0xFFFFFFFF;
public const uint INFINITE = 0xFFFFFFFF;
public const uint WAIT_OBJECT_0 = 0;
public const uint WAIT_ABANDONED_0 = 0x00000080;
}
}
}
Acredito que o cenário descrito deva ser bastante comum para os aplicativos de interface do usuário, mas encontrei muito pouco material sobre esse assunto.Idealmente, o processo da tarefa em segundo plano deve ser projetado da maneira que não requer uma bomba de mensagens para suportar o cancelamento síncrono, mas acho que isso nem sempre é possível.
Estou esquecendo de algo? Existem outras formas / padrões, talvez mais portáteis, de lidar com isso?