ConfigureAwait (false)가 기본 옵션이 아닌 이유는 무엇입니까?

ConfigureAwait (false)가 기본 옵션이 아닌 이유는 무엇입니까?

---

아시다시피 Task.ConfigureAwait(false)동기화 컨텍스트를 캡처 할 필요가없는 코드에서 작업을 기다리고있을 때 호출하는 것이 좋습니다 . 그렇지 않으면 교착 상태 가 발생할 수 있기 때문 입니다.

얼마나 자주 동기화 컨텍스트를 캡처해야합니까? 나는 거의 연습하지 않습니다. 대부분의 상황에서 나는 거의 Task.ConfigureAwait(false)항상 사용하도록 강요하는 "라이브러리"코드로 작업 하고 있습니다.

제 질문은 매우 간단합니다. 왜 Task.ConfigureAwait(false)작업의 기본 옵션이 아닌가? "고수준"코드를 사용하도록하는 것이 훨씬 낫지 Task.ConfigureAwait(true)않습니까? 그것에 대한 역사적인 이유가 있습니까, 아니면 내가 뭔가를 놓치고 있습니까?

---

작동 대부분의 코드 .ConfigureAwait(false)로, subobtimal 있지만, 또한 작동합니다 .ConfigureAwait(true). 예, 모든 코드는 아니지만 여전히 대부분입니다. 현재 기본값은 일반적인 프로그래머가 슬프게도 이해하지 못하는 설정을 변경하지 않고도 가장 높은 비율의 코드가 작동하도록합니다.

다른 기본값은 왜 코드가 작동하지 않는지에 대한 수천 개의 질문으로 이어질 뿐이며, 더 나쁜 것은 "마이크로 소프트가 안타깝 네요 Control.CheckForIllegalCrossThreadCalls = false;. 모든 프로그램에서 작성하게합니다 . 왜 이것이 기본값이 아닌가?" 실제로 적절한 .ConfigureAwait(true)호출을 추가하는 것보다 .

---

해당 링크에서 두 번째 예제 솔루션을보십시오.

public async void Button1_Click(...)
{
  var json = await GetJsonAsync(...);
  textBox1.Text = json;
}

public class MyController : ApiController
{
  public async Task<string> Get()
  {
    var json = await GetJsonAsync(...);
    return json.ToString();
  }
}

기본 동작이 ConfigureAwait(false)이면 textBox1.Text = json;명령문은 UI 스레드 대신 임의의 스레드 풀 스레드에서 실행됩니다.

두 조각 모두 누군가가 합리적으로 작성할 수있는 코드처럼 보이며 기본적으로 그중 하나가 손상되어야합니다. 교착 상태는 스레드가 안전하지 않은 액세스보다 훨씬 덜 위험하고 감지하기 쉽기 ConfigureAwait(true)때문에 기본값으로 선택하는 것이 더 보수적 인 선택입니다.

---

그냥 있기 때문에 당신의 일반적인 사용 사례가 ConfigureAwait (거짓)가 필요합니다, 그것은이 "올바른"또는 가장 많이 사용되는 옵션입니다 것을 의미하지 않는다.

async / await가 설계된 것 중 하나는 반응 형 GUI 프로그램을 작성하는 것입니다. 이러한 경우 UI 업데이트는 대부분의 Windows GUI 플랫폼의 기본 스레드에서만 발생할 수 있으므로 일부 작업을 Task로 오프로드 한 후 UI 스레드로 돌아가는 것이 중요합니다. Async / await는 GUI 개발자가 올바른 일을하도록 도와줍니다.

이것이 기본 옵션이 더 나은 유일한 예는 아닙니다. 추측 만 할 수는 있지만, ConfigureAwait 기본값에 대한 결정은 비동기가 가능한 한 적은 마찰로 작동하는지 확인하는 데 기반을두고 있다고 생각합니다. 모든 사람이 프레임 워크를 작성하는 것은 아닙니다.

참조 URL : https://stackoverflow.com/questions/26681332/why-configureawaitfalse-is-not-the-default-option