비동기/기본 구현 대기

Question

This proposal은 async 함수가 ES2017 사양에서이 확인을 찾을 수는 없지만 기능이 생성기 기능을 사용할 수 있다고 제안합니다.

는 또한, 발전기 프로토 타입 크롬/Node.js를에 엉망이 될 때, async 기능에 영향을 줄 수하지 않는 것,이 GeneratorFunction 적어도 직접 AsyncFunction에서 사용하지 않는 것을 제안 :

Object.getPrototypeOf((function *() {}).prototype).next = null; 

(async() => { 
    return await Promise.resolve(1); 
})() 
.then(console.log); 

async/await은 기존 네이티브 구현에서 정확히 어떻게 작동합니까?

Promise/제안자가 제안한 발전기 기능 접근법보다 구현이 더 효과적이며 일반적으로 Babel 및 TypeScript에서 구현됩니까?

Answer 1

내가 아는 한, 생성자 함수는 async/await의 동작을 모방하는 데 사용됩니다. typescript를 사용하면 javascript로 컴파일되고 설정에 따라 생성기 구현에 async/await 구문을 컴파일합니다.

https://basarat.gitbooks.io/typescript/docs/async-await.html 그래서 당신은 내가 생각 전혀 타이프에서 그들을 사용하는 방법에 대한 걱정한다 : 여기에 편집에 대한

더.

기본 구현에서는 생성자를 사용하지 않는다고 가정합니다. 기본적으로 약속 작업을위한 구문 설탕이어야합니다.

Answer 2

기존의 네이티브 구현에서 async/await은 정확히 어떻게 작동합니까? 우리가 실제 native implementation of async await in v8 보면

우리는 분명히 또한 parser에 명확하게 비동기 await를을 desugaring의 발전기 약속 자연 상태, 비동기 기다리고 구현의 명백한 기준으로 모두 약속과 발전기를 볼 수 있습니다.

ES 스펙과 관련하여, 스펙이 실행 컨텍스트 스위칭의 실제 구현을 직접 언급하지는 않지만 Promise.resolve이 사용하는 것과 동일한 Perform ! Call(promiseCapability.[[Resolve]] 메커니즘의 사용을 암시합니다. 따라서 실행중인 실행 컨텍스트 토글 링 asyncContext을 처리 할 수있는 가능한 "메커니즘"을 주관적으로 암시합니다. 발전기 프로토 타입 크롬/Node.js를에 엉망이되는 경우를

또한, 비동기 기능에 영향을 줄 수하지 않는 것,이 GeneratorFunction 적어도 직접 AsyncFunction에서 사용하지 않는 것을 제안 :

런타임의 generator 및 async 함수는 모두 Function 개체의 하위 항목이지만 서로 상속하지 않으므로 커밋 된 변경 내용이 표시되지 않습니다.

특정 호스트 개체 또는 메서드의 실제 기본 구현은 컴파일 된 카운터 파트 및 해당 종속성의 런타임 실행에 반드시 연결될 필요는 없습니다. Function.prototype.call =() => {}을 다시 할당하여 함수의 기능을 변경할 수없는 것과 같은 방식입니다 %call%은 기본 레벨 구현이므로

구현은 제안에 의해 제안되고 일반적으로 바벨과 타이프 라이터로 구현 약속/발전기 기능 접근 가능한 것보다 더 확대됨에 있습니까?

은 JS 엔진에 의존하며 컴파일 수준의 최적화 및 deoptimizations을 구현,하지만 그것은 끊임없는 변화, 때로는 기본 구현 it happened with es5 map, forEach vs lodash counterparts처럼, 제 3 자 lib 디렉토리 구현보다 느린에 따라, 그러나 대부분의 경우 네이티브 수준의 구현은 기계 코드에 한 단계 가까이 있기 때문에 타의 추종을 불허합니다. 예를 들어 여기에 바벨에 사용 된 jsperf with 2x prevalence of async-await over regenerator이 있습니다.