async & await-대안에 대한 설문 조사 [닫기]

c # 5에 무엇이 저장되어 있는지 알았 으므로, 어제 PDC10 에서 Anders Heijsberg가 발표 한 ' Asynchrony '에 대한 두 가지 새로운 키워드의 선택에 영향을 줄 수있는 여지가 여전히 남아 있습니다.

async void ArchiveDocuments(List<Url> urls) {
    Task archive = null;
    for(int i = 0; i < urls.Count; ++i) {
        var document = await FetchAsync(urls[i]);
        if (archive != null)
            await archive;
        archive = ArchiveAsync(document);
    }
}

Eric Lippert 는 현재 두 키워드의 선택과 유용성 연구에서 오해 된 방식에 대해 설명합니다. 의견에는 몇 가지 다른 제안이 있습니다.

답변 당 하나의 제안, 중복이 표시됩니다.

의 의미 / 필요성에 대해 명확하지 않다는 점을 감안할 때 async실제로 논쟁 할 수는 없지만 교체를위한 최선의 제안 await은 다음과 같습니다.

yield while (봐! 새로운 키워드 없음)

참고 좀 더 이것에 대해 생각을 가지고, 나는 다시 사용 여부를 궁금해 while이런 방식으로는 좋은 아이디어이다 - 자연적인 경향이 이후 부울을 기대하는 것입니다.

(생각 : 좋은 키워드를 찾는 것은 좋은 도메인 이름을 찾는 것과 같습니다.)

키워드가없는 것은 어떻습니까?

컴파일러가 비동기 메소드를 호출 할 때 그 결과를 원한다는 것을 깨닫기를 원합니다.

Document doc = DownloadDocumentAsync();

그게 다야. 사람들이이 문제에 대한 키워드를 생각하는 데 어려움을 겪는 이유는 "일이 완벽하게 정상적으로 이루어 졌다면 할 일"에 대한 키워드를 가지고 있기 때문입니다. 이것이 기본값이어야하며 키워드는 필요하지 않습니다.

최신 정보

필자는 원래 컴파일러가 수행해야 할 작업을 파악하기 위해 형식 유추로 영리해야한다고 제안했습니다. 이것에 대해 더 생각하면 CTP에서 기존 구현을 그대로 유지하지만 몇 가지 간단한 추가를 수행하여 await키워드를 명시 적으로 사용해야하는 경우를 줄 입니다.

우리는 속성을 발명합니다 : [AutoAwait]. 이것은 메소드에만 적용 할 수 있습니다. 이것을 메소드에 적용하는 한 가지 방법은이를 표시하는 것 async입니다. 그러나 직접 수행 할 수도 있습니다. 예 :

[AutoAwait]
public Task<Document> DownloadDocumentAsync()

그런 다음 모든 async메소드에서 컴파일러는에 대한 호출을 기다리고 있다고 가정 DownloadDocumentAsync하므로 지정할 필요가 없습니다. 해당 메소드를 호출하면 자동으로 대기합니다.

Document doc = DownloadDocumentAsync();

이제, "영리하게"하고를 얻으려면 Task<Document>operator를 사용하면 start메소드 호출 전에 만 표시 될 수 있습니다.

Task<Document> task = start DownloadDocumentAsync();

깔끔합니다. 이제 일반 메소드 호출은 일반적으로 의미하는 바를 의미합니다. 메소드가 완료 될 때까지 기다리십시오. 그리고 start다른 것을 나타냅니다 : 기다리지 마십시오.

async메소드 외부에 나타나는 코드의 경우 메소드를 호출 할 수있는 유일한 [AutoAwait]방법은 앞에 접두어를 붙이는 것입니다 start. 이렇게하면 async메소드에 표시되는지 여부에 관계없이 동일한 의미의 코드를 작성하게됩니다 .

욕심이 나기 시작합니다! :)

먼저 async인터페이스 메소드에 적용 하고 싶습니다 .

interface IThing
{
    async int GetCount();
} 

그것은 기본적으로 구현 메소드가 Task<int>또는 호환되는 것을 반환해야 await하며 메소드를 호출하면 [AutoAwait]동작 을 얻습니다 .

또한 위의 방법을 구현할 때 다음과 같이 쓸 수 있기를 원합니다.

async int GetCount()

따라서 Task<int>반환 유형 으로 언급 할 필요가 없습니다 .

또한 async대리자 유형 (결국 하나의 메서드가있는 인터페이스와 유사)에 적용하고 싶습니다. 그래서:

public async delegate TResult AsyncFunc<TResult>();

async대표는이 - 당신은 그것을 짐작 - [AutoAwait]행동. async메소드 에서 호출 할 수 있으며 자동으로 await선택됩니다 (단지 선택하지 않는 한 start). 그리고 당신이 말하면 :

AsyncFunc<Document> getDoc = DownloadDocumentAsync;

그냥 작동합니다. 메소드 호출이 아닙니다. 아직 시작된 작업 async delegate이 없습니다 - 작업이 아닙니다. 작업을 수행하는 공장입니다. 당신은 말할 수 있습니다 :

Document doc = getDoc();

그러면 작업이 시작되고 완료 될 때까지 기다렸다가 결과가 나타납니다. 또는 당신은 말할 수 있습니다 :

Task<Document> t = start getDoc();

따라서 "배관"이 누출되는 곳 중 한 곳은 async메서드에 대리자를 만들려면 async delegate형식 을 사용해야한다는 것 입니다. 따라서 대신 Func에을 말해야합니다 AsyncFunc. 언젠가는 그런 종류의 것이 개선 된 유형 유추에 의해 고정 될 수 있습니다.

또 다른 질문은 일반적인 (비동기 적 인) 방법으로 시작한다고 말하면 어떻게됩니까? 분명히 컴파일 오류가 안전한 옵션입니다. 그러나 다른 가능성이 있습니다.

hearken unto AsyncFetch(…)

(당신이 그것을 얻지 못하면, Eric의 블로그 항목을 읽으십시오 . 적어도 그것보다 낫습니다 for sooth Romeo wherefore art thou AsyncFetch(…))

나는 async괜찮다고 생각 하지만 아마도 ASP.NET 비동기 페이지와 연결하기 때문일 수 있습니다.

를 들어 await키워드 내가 선호하는 continue after나 resume after.

나는 하지 않습니다 같은 yield의미가 방법이 실제로 실행을 양보하지 않을 수 있도록하기 때문에, 또는 그 변종의; 작업 상태에 따라 다릅니다.

Eric의 블로그에 댓글을 달았는데 동일한 키워드를 사용하는 데 아무런 문제가 없습니다. async

var data = async DownloadFileAsync(url);

파일을 비동기 적으로 다운로드하고 싶다고 표현하고 있습니다. 여기에는 약간의 중복성이 있습니다. "비동기"는 메서드 이름에 있기 때문에 두 번 나타납니다. 컴파일러는 매우 영리하며 "Async"로 끝나는 메소드가 사실상 비동기 메소드라는 규칙을 감지하고 컴파일 된 코드에 추가 할 수 있습니다. 대신에 그냥 전화하고 싶을 수도 있습니다

var data = async DownloadFile(url);

동기식 호출과 반대로

var data = DownloadFile(url);

도대체 async 키워드가 선언에 있기 때문에 동일한 방법으로 정의 할 수 있어야합니다. 왜 각 메소드 이름에 "Async"를 수동으로 추가해야합니까? 컴파일러가 우리를 위해 할 수 있습니다.

async = task- 함수를 수정하여 작업을 반환하므로 키워드 "task"를 사용하지 않는 이유는 무엇입니까?

await = finish-기다릴 필요는 없지만 결과를 사용하기 전에 작업을 "완료"해야합니다.

나는 좋아한다 yield until. yield while이미 제안했듯이 훌륭하고 새로운 키워드를 소개하지 않지만 '정지'가 동작을 조금 더 잘 포착한다고 생각합니다.

yield <something>yield는 이미 나머지 방법을 계속 잘 만드는 아이디어를 포착하기 때문에 좋은 생각 이라고 생각 합니다. 어쩌면 누군가는 "때까지"보다 더 나은 단어를 생각할 수 있습니다.

comefromINTERCAL의 COMEFROM 선언 에서 내가 본 첫 번째 용도 로 Aaron G의 제안에 대한 투표를 등록하고 싶습니다 . 아이디어는 (멀리 점프 일종의 GOTO의 반대의 점이다 에서 이 코드 점프에 어떤 장소를 만드는의 GOTO 문) 에 COMEFROM 문.

우리는 Task<T>s를 다루기 때문에 다음과 start같이 명령문 앞에 키워드로 사용 하는 것은 어떻 습니까?

start var document = FetchAsync(urls[i]);

F # async은 비동기 워크 플로에서 키워드를 사용한다는 점에 주목할 가치가 있습니다 . 이는 C # 5의 새로운 비동기 기능과 거의 동일합니다. 그러므로 나는 그 것을 동일하게 유지할 것입니다

awaitF # 의 키워드는 let!대신을 사용 합니다 let. C #에는 동일한 할당 구문이 없으므로 =부호 오른쪽에 무언가가 필요합니다 . Benjol이 말했듯이, 그것은 yield거의 같은 변형이어야합니다.

yield async FetchAsync(..)

이것은 async호출하는 메소드에 적용 해야하는 수정 자 와 완벽하게 일치합니다 . 또한 현재의 의미 yield return, 당신은 반환 하고 ,이 경우는 비동기 방식으로 실행을 산출하고있는 동안 열거 코드에 수익률 실행.

미래에에 다른 용도가있을 것이라고 가정 해 보겠습니다. 대부분 동일한 작업을 수행하기 위해 다른 키워드를 사용하는 대신 x가 빛나는 새로운 기능인 where를 yield추가 할 수 있습니다 yield x.

솔직히 말해서 나는 '실행력을 포기하지 않는다'는 주장을 이해하지 못한다. 결국, 다른 메소드를 호출하는 시점이 이미 해당 메소드에 대한 '수율'이 아닌가? 비동기인지 여부에 관계없이? 여기에 뭔가 빠졌습니까?

그리고 당신을 위해 좋은 경우 async반환 기적하지만 키워드가 방법이 비동기 적으로 실행 것이라는 가능성 기회가 있음을 의미하고 다른 방법으로 실행을 산출 할 거라고한다 필요. 메소드가 실제로 비동기 호출을 수행하는지 여부에 관계없이 메소드가이를 설명해야합니다.

IMO 다양한 '수율이 아닌'사례는 구현 세부 사항이라고 생각합니다. 차라리 언어의 일관성 (즉, 재사용 yield)을 보증하고 싶습니다 .

어떻게 약 complete에서와 같이 "나는 작업이 완료 싶다"?

Task<byte[]> downloadTask = DownloadFileAsync(url);
byte[] data = complete downloadTask;

task(메소드 선언 용) 및 async(메소드 본문 내)