title: How can I suppress ExecutionContext capturing the current SynchronizationContext?
body: <p>My question was raised by one of the examples from <a href="http://blogs.msdn.com/b/pfxteam/archive/2012/06/15/executioncontext-vs-synchronizationcontext.aspx" rel="nofollow">this article</a>:</p>
  
  <blockquote>
  <pre><code>private void button1_Click(object sender, EventArgs e)  { 
      button1.Text = await Task.Run(async delegate 
      { 
          string data = await DownloadAsync(); 
          return Compute(data); 
      });  
  }
  </code></pre>
    
    <p>Here’s what my mental model tells me will happen with this code.  A
    user clicks button1, causing the UI framework to invoke button1_Click
    on the UI thread.  The code then kicks off a work item to run on the
    ThreadPool (via Task.Run).  That work item starts some download work
    and asynchronously waits for it to complete.  A subsequent work item
    on the ThreadPool then does some compute-intensive operation on the
    result of that download, and returns the result, causing the Task that
    was being awaited on the UI thread to complete.  At that point, the UI
    thread processes the remainder of this button1_Click method, storing
    the result of the computation into the button1’s Text property.</p>
    
    <p>My expectation is valid if SynchronizationContext doesn’t flow as part
    of ExecutionContext.  If it does flow, however, I will be sorely
    disappointed.  Task.Run captures ExecutionContext when invoked, and
    uses it to run the delegate passed to it.  That means that the UI
    SynchronizationContext which was current when Task.Run was invoked
    would flow into the Task and would be Current while invoking
    DownloadAsync and awaiting the resulting task.  That then means that
    the await will see the Current SynchronizationContext and Post the
    remainder of asynchronous method as a continuation to run back on the
    UI thread.  And that means my Compute method will very likely be
    running on the UI thread, not on the ThreadPool, causing
    responsiveness problems for my app.</p>
  </blockquote>
  
  <p>Let's say instead of the example in the article I have:</p>
  
  <pre><code>private void button1_Click(object sender, EventArgs e)  { 
      button1.Text = await DownloadAndComputeAsync(); 
  }
  
  // Can't be changed
  private async Task&lt;string&gt; DownloadAndComputeAsync() {
      return await Task.Run(async delegate 
      { 
          string data = await DownloadAsync(); 
          return Compute(data); 
      });  
  }
  </code></pre>
  
  <p>And for some reason I can't change the code in <code>DownloadAndComputeAsync</code> to use <code>ConfigureAwait(false)</code>, perhaps because it's in a library or other code I don't control.</p>
  
  <p>Is there a way I can suppress capture of the UI's SynchronizationContext as part of the ExecutionContext? </p>
  
  <p>The article I linked above mentions an internal version of Task.Run that suppresses capture of the SynchronizationContext, but it's, well, internal. If it wasn't internal you could do something like this:</p>
  
  <pre><code>private void button1_Click(object sender, EventArgs e)  { 
      button1.Text = await Task.Run(DownloadAndComputeAsync, InternalOptions.DoNotCaptureSynchronizationContextInExecutionContext);
  }
  
  // Can't be changed
  private async Task&lt;string&gt; DownloadAndComputeAsync() {
      return await Task.Run(async delegate 
      { 
          string data = await DownloadAsync(); 
          return Compute(data); 
      });  
  }
  </code></pre>
  
  <h2>Use cases</h2>
  
  <p>I don't have a case where I know I'm going to want/need to use this, but after reading the article I linked at the top I can think of a couple places where it might be useful.</p>
  
  <ol>
  <li><p>If from the UI context I'm using a library that doesn't use <code>ConfigureAwait(false)</code> and ends up doing significant work on the UI thread. Admittedly I'd probably stop using the library in this case if I could.</p></li>
  <li><p>The current recommended best practice seems to be one of the following</p>
  
  <ol>
  <li>Use <code>ConfigureAwait(false)</code> everywhere unless you know you're going to need to come back to the current context. The downside to this is that <code>ConfigureAwait(false)</code> is pretty ugly and affects code readability negatively (imo).</li>
  <li>Use <code>ConfigureAwait(false)</code> only in library code but be aware in all internal code whether or not a given async method might be used from e.g. the UI context and use <code>ConfigureAwait(false)</code> only where absolutely required. This seems less than desirable as it means classes must be aware of whether or not their async methods may ever be called on, e.g., the UI context.</li>
  </ol>
  
  <p>I was wondering if there might be a third possibility: require that in internal code any time an async method is called on, e.g., the UI context that the code in the event handler or similar is responsible for making sure that the async method won't have the UI context as its current context and therefore does not need to use <code>ConfigureAwait(false)</code> on the off chance that it's being called on the UI context. The upside to this is that all internal non-UI code does not need to use <code>ConfigureAwait(false)</code> even if it's called from an event handler and that all context aware code is limited to just UI code in, e.g., event handlers.</p></li>
  </ol>