비동기 CTP - 앰비언트 취소 및 IP 처리

Question

비동기 CTP는 내 환경 SynchronizationContext을 통한 암시 적 스케줄링을 촉진한다는 것을 염두에두고 내 CancellationToken 및 IProgress도 역시 주변 환경으로 만들어서는 안되는 이유가 무엇입니까?

나는 명시 적 스케줄링을 위해 TaskScheduler을 전달하는 것과 같이 현재 이러한 메소드를 전달하고 있습니다. 그러나 스케줄러가 이제는 대기로 간주되기 때문에 퍼즐의 다른 부분에 대해 동일한 규칙을 따르지 않을 수 있습니까?

Answer 1

CancellationToken이 보다 가능성이 큽니다. 을 사용하면 서로 다른 수준의 T이 서로 다른 경우가 많습니다 (상위 수준 async 방법은 하위 수준 await 통화의 진행 상태 알림을 결합 함). CancellationToken을 사용하면 동일한 토큰이 거의 항상 하위 레벨 async 메쏘드로 전달됩니다 (소거가 지원된다고 가정 할 때). CancellationToken은 일부 고급 조합기를 지원하지만 거의 사용하지 않습니다.

첫 번째 단점은 작업 기반 비동기 패턴에서 벗어나는 것입니다. Microsoft 또는 타사 코드는 명시 적으로 CancellationToken을 취해야 함을 명심해야합니다. 가장 낮은 수준의 async 메서드에서 앰비언트 컨텍스트 외부로 명시 적으로 가져와야합니다. 또한 나중에 코드 기반을 유지하는 프로그래머는 TAP을 기대할 수 있습니다.

구현을 고려할 때 문제가 있습니다. 스레드 컨텍스트를 변경하더라도 암시적인 CancellationToken이 async 메서드의 호출을 따르길 원할 것입니다. 제 말은 다음과 같습니다. A 메서드는 B 메서드의 결과를 기다리기 전에 ConfigureAwait(false) 메서드를 호출합니다. 한 스레드에서 다른 스레드로 비동기 실행 컨텍스트를 따라야하기 때문에 간단한 스레드 로컬 정적 속성을 사용할 수 없습니다.

(아마도 CallContext 클래스를 사용하여)이 작업을 수행하는 방법에 대해 읽은 것처럼 보이지만 실행하자마자 성능 탱크 (실행 컨텍스트 마이그레이션 코드는 기본 시나리오에 맞게 최적화되어 있습니다).