Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Assuming I read the question correctly, you are worried about the following sequence of events:</p> <ol> <li>The button is clicked, task <code>T0</code> is scheduled on the thread pool, continuation <code>C0</code> is scheduled as a continuation of <code>T0</code>, to be run on the synchronization context's task scheduler</li> <li>The button is clicked again. Let's say the message pump is busy doing something else, so now the message queue consists of one item, the click handler.</li> <li><code>T0</code> completes, this causes <code>C0</code> to be posted to the message queue. The queue now contains two items, the click handler and the execution of <code>C0</code>.</li> <li>The click handler message is pumped, and the handler signals the token driving the cancellation of <code>T0</code> and <code>C0</code>. Then it schedules <code>T1</code> on the thread pool and <code>C1</code> as a continuation in the same manner as step <code>1</code>.</li> <li>The 'execute <code>C0</code>' message is still in the queue, so it gets processed now. Does it execute the continuation you intended to cancel?</li> </ol> <p>The answer is no. <a href="http://msdn.microsoft.com/en-us/library/system.threading.tasks.taskscheduler.tryexecutetask.aspx" rel="noreferrer">TryExecuteTask</a> will not execute a task which has been signaled for cancellation. It's implied by that documentation, but spelled out explicitly on the <a href="http://msdn.microsoft.com/en-us/library/system.threading.tasks.taskstatus.aspx" rel="noreferrer">TaskStatus</a> page, which specifies</p> <blockquote> <p><em>Canceled</em> -- The task acknowledged cancellation by throwing an OperationCanceledException with its own CancellationToken while the token was in signaled state, <strong>or the task's CancellationToken was already signaled before the task started executing</strong>.</p> </blockquote> <p>So at the end of the day <code>T0</code> will be in the <code>RanToCompletion</code> state and <code>C0</code> will be in the <code>Canceled</code> state.</p> <p>This is all, of course, assuming that the current <code>SynchronizationContext</code> does not allow tasks to be run concurrently (as you are aware, the Windows Forms one does not -- I'm just noting that this is not a requirement of synchronization contexts)</p> <p>Also, it's worth noting that the exact answer to your final question about whether the cancellation token is checked in the context of when cancellation is requested or when the task is executed, the answer is really <em>both</em>. In addition to the final check in <code>TryExecuteTask</code>, as soon as cancellation is requested the framework will call <code>TryDequeue</code>, an optional operation that task schedulers can support. The synchronization context scheduler does not support it. But if it somehow did, the difference might be that the 'execute <code>C0</code>' message would be ripped out of the thread's message queue entirely and it wouldn't even try to execute the task.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload