Quando descartar o CancellationTokenSource?

A classeCancellationTokenSource é descartável. Uma rápida olhada no Reflector comprova o uso deKernelEvent, um recurso não gerenciado (muito provavelmente). Desde aCancellationTokenSource não possui finalizador; se não descartá-lo, o GC não o far

Por outro lado, se você olhar para os exemplos listados no artigo do MSDNancelamento em Threads Gerenciad, apenas um trecho de código descarta o toke

Qual é a maneira correta de descartá-lo em código?

Você não pode quebrar o código iniciando sua tarefa paralela comusing se você não esperar por isso. E faz sentido ter o cancelamento apenas se você não esperaClaro que você pode adicionarContinueWith na tarefa com umDispose ligue, mas é esse o caminho a seguir? E as consultas canceláveis do PLINQ, que não são sincronizadas novamente, mas apenas fazem alguma coisa no final? Digamos.ForAll(x => Console.Write(x))? É reutilizável? O mesmo token pode ser usado para várias chamadas e depois descartá-lo com o componente host, digamos, controle da interface do usuário?

Por que não tem algo como umReset método de limpezaIsCancelRequested eToken field Suponho que não seja reutilizável, portanto, toda vez que você inicia uma tarefa (ou uma consulta PLINQ), deve criar uma nova. É verdade? Se sim, minha pergunta é qual é a estratégia correta e recomendada para lidar comDispose naqueles muitosCancellationTokenSource instâncias?

questionAnswers(7)

yourAnswerToTheQuestion