Design: 제안: 기다리다

뛰어난 필력! 나는 호스트 제어 서스펜션의 아이디어를 좋아합니다. @rossberg 의 제안은 또한 기능적 효과 시스템에 대해 논의하고 있으며 나는 그 시스템에 대한 전문가는 아니지만 언뜻 보기에는 동일한 비-로컬 제어 흐름 요구를 충족할 수 있는 것처럼 보입니다.

관련: "위의 내용을 감안할 때 자연스러운 구현은 일시 중지할 때 스택을 복사하는 것입니다." 이것은 실행 스택에서 어떻게 작동할까요? 대부분의 JIT 엔진이 JS와 wasm 간에 기본 C 실행 스택을 공유한다고 생각하기 때문에 이 컨텍스트에서 저장 및 복원이 무엇을 의미하는지 잘 모르겠습니다. 이 제안은 wasm 실행 스택이 어떻게든 가상화되어야 한다는 것을 의미합니까? 파이썬이 https://github.com/stackless-dev/stackless/wiki와 유사한 작업을 시도할 때 이와 같은 C 스택의 사용을 피하는 IIUC는 꽤 까다로웠습니다.

@sbc100님과 비슷한 고민을 하고 있습니다. 특히 VM에 아직 GC 구현이 없는 경우 스택을 복사하는 것은 본질적으로 상당히 어려운 작업입니다.

@sbc100

이 제안은 wasm 실행 스택이 어떻게든 가상화되어야 한다는 것을 의미합니까?

나는 그것에 대한 전문가가 아니기 때문에 이것을 VM 구현자에게 맡겨야 합니다. 그리고 스택리스 파이썬에 대한 연결을 이해하지 못하지만, 아마도 그것이 연결을 이해하기에 충분히 잘 모를 것입니다. 죄송합니다!

그러나 일반적으로 다양한 코루틴 접근 방식 은 낮은 수준에서 스택 포인터를 조작하여 작동합니다. 이러한 접근 방식은 여기에서 선택 사항일 수 있습니다. 이러한 접근 방식의 일부로 스택을 복사해야 하는 경우에도 이 컨텍스트에서 허용 가능한 오버헤드가 있음을 지적하고 싶었습니다.

(우리는 이러한 접근 방식이 wasm VM에서 작동할 수 있는지 확실하지 않습니다. 구현자가 예 또는 아니요, 더 나은 옵션이 있는지 여부를 듣기를 바랍니다!)

@lachlansneff

일을 더 쉽게 만드는 GC가 무엇을 의미하는지 자세히 설명해 주시겠습니까? 나는 따르지 않는다.

@kripken GC는 종종(항상 그런 것은 아님) 스택을 이동할 수 있는 기능이 있습니다. 이는 스택의 포인터를 새 스택을 가리키도록 다시 작성해야 하는 경우에 필요합니다. 아마도 JSC에 대해 더 많이 알고 있는 사람이 이를 확인하거나 거부할 수 있습니다.

@lachlansneff

감사합니다. 이제 말씀하신 내용을 알았습니다.

이를 위해 스택을 완전히 걷는 것(각 로컬을 끝까지 식별하는 등)이 필요하다고 제안하지 않습니다 . (다른 가능한 접근 방식에 대해서는 저수준 코루틴 구현 방법에 대한 내 마지막 주석의 링크를 참조하십시오.)

제안서에서 "스택 복사"라는 용어에 대해 사과드립니다. 귀하와 @sbc100 의 피드백을 기반으로 할 때 충분히 명확하지 않은 것으로 보입니다. 다시 말하지만, 우리는 특정 VM 구현 방식을 제안하고 싶지 않습니다. 우리는 단지 어떤 접근 방식에서 스택 복사가 필요한 경우 속도에 문제가 없을 것이라고 말하고 싶었습니다.

특정 구현 방식을 제안하기 보다는 VM 사용자의 의견을 듣고 싶습니다.

이 제안을 보게 되어 매우 기쁩니다. Lucet은 현재 yield 및 resume 연산자를 가지고 있으며 Rust 호스트 환경에서 실행되는 비동기 코드와 상호 작용하는 데 정확히 사용합니다.

우리의 디자인은 이미 Wasm 실행을 위해 별도의 스택을 유지 관리하기로 약속했기 때문에 이것은 Lucet에 추가하는 것이 매우 간단했지만 그렇지 않은 VM에 대해 일부 구현 어려움을 나타낼 수 있다고 상상할 수 있습니다.

이 제안은 훌륭하게 들립니다! 우리는 잠시 동안 wasmer-js에서 비동기 코드를 관리하는 좋은 방법을 찾으려고 노력했습니다(브라우저 컨텍스트에서 VM 내부에 액세스할 수 없기 때문에).

특정 구현 방식을 제안하기 보다는 VM 사용자의 의견을 듣고 싶습니다.

아마도 비동기 함수에 대한 콜백 전략을 사용하는 것이 언어에 구애받지 않는 방식으로 작업을 진행하는 가장 쉬운 방법일 수 있다고 생각합니다.

wasm-bindgen-futures 를 사용하여 Rust 함수 내부의 JsPromise 에서 .await 를 호출할 수 있는 것 같습니까? 여기에 제안된 await 명령 없이 어떻게 작동할 수 있습니까? 내 무지에 대해 유감스럽게 생각합니다. 저는 wasm 내부에서 fetch를 호출하는 솔루션을 찾고 있으며 Asyncify에 대해 배우고 있지만 Rust 솔루션이 더 간단합니다. 여기서 내가 놓치고 있는 것이 무엇입니까? 누군가 나를 위해 분명히 할 수 있습니까?

나는 이 제안에 대해 매우 흥분된다. 제안의 주요 장점은 단순하다는 점입니다. wasm의 POV와 동기화되는 API를 구축할 수 있고 콜백 및 비동기/대기에 대해 명시적으로 생각할 필요 없이 애플리케이션을 훨씬 쉽게 이식할 수 있기 때문입니다. 단일 네이티브 API를 사용하여 WASM 및 WebGPU 기반 머신 러닝 을 네이티브 wasm vms로 가져오고 웹과 네이티브 모두에서 실행할 수 있습니다.

논의할 가치가 있다고 생각하는 한 가지는 잠재적으로 await를 호출하는 함수의 서명입니다. 다음 기능이 있다고 상상해보십시오.

int test() {
   await();
   return 1;
}

해당 함수의 서명은 () => i32 입니다. 새로운 제안에 따라 테스트 호출은 i32 또는 Promise<i32> 를 반환할 수 있습니다. 사용자에게 새 서명을 정적으로 선언하도록 요청하는 것이 더 어렵다는 점에 유의하십시오(코드 이식 비용이 발생하고 호출이 기다리고 있는지 모르는 함수 내부의 간접 호출이 될 수 있기 때문).

런타임 중에 대기가 허용됨을 나타내기 위해 내보낸 함수(예: 비동기 호출)에 별도의 호출 모드가 있어야 합니까?

용어적으로 제안하는 작업은 운영 체제에서 yield 작업 과 같습니다. finsih에 대한 시스템 호출을 기다리기 위해 OS(이 경우에는 wasm VM)에 제어를 양보하기 때문입니다.

이 제안을 제대로 이해했다면 JS의 await 는 async 함수에서만 사용할 수 있다는 제한을 없애는 것과 거의 같다고 생각합니다. 즉, wasm 측에서 waitref 는 externref await 명령 대신 $await : [externref] -> [] 가져온 함수를 가질 수 있고 JS 측에서는 가져올 함수로 foo(promise) => await promise 를 제공할 수 있습니다. 다른 방향으로, async 함수 외부의 Promise에서 await 를 원하는 JS 코드라면 단순히 await 를 호출하는 wasm 모듈에 해당 promise를 제공할 수 있습니다. 입력에. 그것이 올바른 이해입니까?

@RossTate 그렇지 않습니다, AIUI. wasm 코드는 await 프라미스( promise1 라고 함)를 수행할 수 있지만 JS가 아닌 wasm 실행만 생성합니다. wasm 코드는 JS 호출자에게 다른 약속( promise2 이라고 함)을 반환합니다. promise1 가 해결되면 wasm 실행이 계속됩니다. 마지막으로, 그 wasm 코드가 정상적으로 종료되면 promise2 는 wasm 함수의 결과로 해결됩니다.

@tqchen

런타임 중에 대기가 허용됨을 나타내기 위해 내보낸 함수(예: 비동기 호출)에 별도의 호출 모드가 있어야 합니까?

흥미롭습니다. 이점은 어디에서 보십니까? 당신이 말했듯이 일반적인 이식 상황에서 내보내기가 결국 await 를 수행할지 여부를 확신할 수 있는 방법이 없으므로 기껏해야 가끔만 사용할 수 있습니다. 이것이 VM 내부에 도움이 될까요?

명시적 선언을 하면 사용자가 의도를 명확하게 명시할 수 있으며 사용자의 의도가 비동기식으로 실행되는 호출을 수행하지 않는 경우 VM에서 적절한 오류 메시지를 throw할 수 있습니다.

사용자의 관점에서 코드 작성을 보다 일관되게 만듭니다. 예를 들어, 테스트가 await를 호출하지 않고 시스템 인터페이스가 자동으로 Promise.resolve(test())를 반환하더라도 사용자는 다음 코드를 작성할 수 있습니다.

await inst.exports_async.test();

wasm-bindgen-futures 를 사용하여 Rust 함수 내부의 JsPromise 에서 .await 를 호출할 수 있는 것 같 습니까? await 명령 없이 어떻게 작동할 수 있습니까? 내 무지에 대해 유감스럽게 생각합니다. 저는 wasm 내부에서 fetch를 호출하는 솔루션을 찾고 있으며 Asyncify에 대해 배우고 있지만 Rust 솔루션이 더 간단합니다. 누군가 나를 위해 분명히 할 수 있습니까?

@malbarbo 유사한 사용 사례에도 불구하고 둘 사이에는 거의 겹치지 않습니다. Rust가 하는 일은 본질적으로 완전한 코루틴이며, 이는 다른 연결된 제안의 범위에 더 가깝습니다.

더 유연하지만 언어와 코드베이스 모두에서 더 많은 참여와 오버헤드가 필요합니다. 기본적으로 async 기능의 개념이 있어야 하고 호출 체인의 모든 단일 기능을 그대로 표시해야 합니다.

이 제안이 대신 달성하려고 하는 것은 호스트 제공 시스템 호출을 기다리는 방법입니다. 여기서 비동기는 구현 세부 사항일 뿐이므로 이러한 함수는 기존 코드베이스의 어디에서나 이전 버전과 호환되는 방식으로 호출될 수 있습니다. 전체 앱이 어떻게 작동하는지 다시 작성해야 합니다. (예를 들어 C/C++/Rust를 포함한 소스 언어는 일반적으로 동기식으로 사용할 수 있을 것으로 예상하지만 예를 들어 웹에서는 그렇지 않은 파일 I/O입니다.)

즉, 웹에는 비동기 API만 있기 때문에 현재 동기 OS API(예 std::fs )를 사용할 수 없습니다. 그러나 이 제안으로 동기 OS API를 사용할 수 있습니다. 내부적으로 Promises를 사용하지만 Rust와 동기적으로 보일 것입니다.

이 제안이 구현되더라도 wasm-bindgen-futures 는 여전히 존재하며 다른 사용 사례( async 기능 실행)를 처리하기 때문에 여전히 유용할 것입니다. 그리고 async 함수는 쉽게 병렬화할 수 있기 때문에 유용합니다.

@RossTate 귀하의 제안은 "대체 접근 방식 고려"에서 다루는 제안과 매우 유사한 것 같습니다.

우리가 고려한 또 다른 옵션은 "이 가져오기가 약속을 반환하는 경우 일시 중지해야 합니다"라고 표시하도록 가져오기를 표시하는 것입니다. JS 또는 wasm 측에서 표시하는 방법에 대한 다양한 옵션을 생각했지만 옳다고 생각되는 것을 찾지 못했습니다. 예를 들어, JS 측에서 가져오기를 표시하면 wasm 모듈은 가져오기가 도착할 때 링크 단계까지 가져오기 호출이 일시 중지되는지 여부를 알지 못합니다. 즉, 가져오기 및 일시 중지 호출이 "혼합"됩니다. 가장 간단한 방법은 이에 대한 새로운 지시인 wait가 명시되어 있는 것 같습니다. 이론적으로 이러한 기능은 웹 외부에서도 유용할 수 있으므로(앞의 참고 사항 참조) 모든 사람을 위한 지침이 있으면 전체적으로 일관성이 향상될 수 있습니다.

시작 기능은 어떻게 처리됩니까? 그것은 정적으로 대기를 허용하지 않습니까, 아니면 어떻게든 Was 인스턴스화와 상호 작용합니까?

@Pauan 우리는 이것을 구체적으로 다루지 않았지만 start 에서도 $ await 를 허용하는 것을 막을 수는 없다고 생각합니다. 이 경우 instantiate{Streaming} 에서 반환된 Promise는 시작 함수가 완전히 실행을 완료했을 때 여전히 자연스럽게 해결/거부됩니다. 유일한 차이점은 await ed promise를 기다리는 것뿐입니다.

즉, 오늘날과 동일한 제한이 적용되며 현재로서는 내보낸 메모리에 액세스해야 하는 경우에는 그다지 유용하지 않습니다.

@RReverser 동기 new WebAssembly.Instance (작업자에서 사용됨)에 대해 어떻게 작동합니까?

시작에 대한 흥미로운 점 @Pauan !

예, 동기식 인스턴스화의 경우 위험해 보입니다 await 가 허용되는 경우 일시 중지된 상태에서 누군가 내보내기를 호출하면 이상합니다. await 을 허용하지 않는 것이 가장 간단하고 안전할 수 있습니다. (아마도 일관성을 위해 비동기식 시작에 있을 수도 있지만, 이를 방지할 중요한 사용 사례가 없는 것 같습니까? 더 많은 생각이 필요합니다.)

(근로자에게 사용되는)?

흠 좋은 지적입니다. 워커에서 사용할 필요 는 없다고 생각하지만 이 API가 이미 존재하기 때문에 프라미스를 반환할 수 있을까요? 표준 API에서 이 작업을 수행하는 것이 좋은 생각인지 확실하지 않지만 다양한 라이브러리의 생성자에서 thenables를 반환하는 반 인기 있는 새로운 패턴으로 보았습니다.

start (트래핑에서와 같이)에서 이를 허용하지 않는 것이 현재로서는 가장 안전하다는 데 동의하며, 향후 변경 사항이 있을 경우 이전 버전과 호환되는 방식으로 이를 변경할 수 있습니다.

내가 뭔가를 놓쳤을 수도 있지만 await 명령어로 WASM 실행이 일시 중지되고 프라미스가 JS로 반환되면 JS가 약속을 기다리지 않고 WASM으로 다시 호출할 때 어떤 일이 발생하는지에 대한 논의가 없습니다.

유효한 사용 사례입니까? 그렇다면 "메인 루프" 애플리케이션이 브라우저에 수동으로 양보하지 않고 입력 이벤트를 수신할 수 있습니다. 대신 그들은 즉시 해결되는 약속을 기다리면서 항복할 수 있습니다.

취소는 어떻게 되나요? JS 약속에서 구현되지 않았으며 이로 인해 몇 가지 문제가 발생합니다.

@강즈

내가 뭔가를 놓쳤을 수도 있지만 await 명령으로 WASM 실행이 일시 중지되고 Promise가 JS로 반환된 다음 JS가 Promise를 기다리지 않고 WASM으로 다시 호출할 때 어떤 일이 발생하는지에 대한 논의는 없습니다.

유효한 사용 사례입니까? 그렇다면 "메인 루프" 애플리케이션이 브라우저에 수동으로 양보하지 않고 입력 이벤트를 수신할 수 있습니다. 대신 그들은 즉시 해결되는 약속을 기다리면서 항복할 수 있습니다.

현재 텍스트는 아마도 그것에 대해 충분히 명확하지 않을 것입니다. 첫 번째 단락의 경우 예, 허용됩니다. "설명" 섹션을 참조하세요. It is ok to call into the WebAssembly instance while a pause has occurred, and multiple pause/resume events can be in flight at once.

두 번째 단락의 경우 아니오 - 이벤트를 더 일찍 가져올 수 없으며 JS가 약속을 더 일찍 해결하도록 할 수 없습니다. 다른 방식으로 요약해 보겠습니다.

• wasm이 Promise A에서 일시 중지되면 호출한 항목으로 다시 빠져 나와 새로운 Promise B를 반환합니다.
• 약속 A가 해결되면 Wasm이 재개됩니다. 이는 정상 시간에 발생하며 , 이는 JS 이벤트 루프에서 모든 것이 정상임을 의미합니다.
• wasm 이 재개 되고 실행이 완료된 후에야 Promise B가 해결됩니다.

따라서 특히 Promise B는 Promise A 이후에 해결되어야 합니다. JS가 얻을 수 있는 것보다 먼저 Promise A의 결과를 얻을 수는 없습니다.

다시 말해서 이 제안의 동작은 Asyncify + 주변에 Promises를 사용하는 일부 JS에 의해 폴리필될 수 있습니다.

@RReverser , 나는 그것들이 동일하다고 생각하지 않지만 먼저 우리가 뭔가를 명확히 해야 한다고 생각합니다(아직 명확하지 않은 경우 누락되어 죄송합니다).

JS에서 동일한 스택의 동일한 wasm 인스턴스로 동시에 여러 호출이 있을 수 있습니다. await 가 인스턴스에 의해 실행되면 어떤 호출이 일시 중지되고 약속을 반환합니까?

두 번째 단락의 경우 아니오 - 이벤트를 더 일찍 가져올 수 없으며 JS가 약속을 더 일찍 해결하도록 할 수 없습니다.

죄송합니다. 제 질문이 명확하지 않은 것 같습니다. 현재 C++의 "main-loop" 앱은 emscripten_set_main_loop 를 사용하여 프레임 기능이 실행될 때마다 제어가 브라우저에 반환되고 입력 또는 기타 이벤트가 처리될 수 있습니다.

이 제안으로 "메인 루프" 앱을 번역하려면 다음이 작동해야 할 것 같습니다. (JS 이벤트 루프를 잘 모르지만)

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM(
    new Promise((resolve, reject) => {
      setTimeout(0, () => resolve());
    })
  ))
}

@Kangz 작동해야 합니다(setTimeout 코드의 인수 순서에 작은 문제가 있고 단순화할 수 있다는 점만 제외).

int main() {
  while (true) {
    frame();
    processEvents();
  }
}

// polyfillable with ASYNCIFY!
void processEvents() {
  __builtin_await(EM_ASM_WAITREF(
    return new Promise(resolve => setTimeout(resolve));
  ));
}

JS에서 동일한 스택의 동일한 wasm 인스턴스로 동시에 여러 호출이 있을 수 있습니다. await가 인스턴스에 의해 실행되면 어떤 호출이 일시 중지되고 약속을 반환합니까?

가장 안쪽에 있는 것. 원하는 경우 나머지를 조정하는 것은 JS 래퍼의 작업입니다.

@Kangz 죄송합니다 그전에 제가 오해했습니다. 예, @RReverser 가 말했듯이 작동해야 하며 여기에 의도된 사용 사례의 좋은 예입니다!

당신이 말했듯이 Asyncify로 폴리필이 가능하며 실제로 __builtin_await 를 emscripten_sleep(0) 에 대한 호출로 대체함으로써 오늘날 Asyncify와 동일한 코드와 동일합니다( setTimeout(0) 수행) .

@RReverser님 , 설명해주셔서 감사합니다. 인스턴스 자체가 아니라 인스턴스에 대한 (가장 최근의) 호출이 일시 중지된다고 설명하는 것이 도움이 될 것이라고 생각합니다.

이 경우 promise-on-await(f) 및 await-for-promise(p) 두 가지 기본 함수를 JS에 추가하는 것과 거의 같습니다. 전자는 f() 를 호출하지만 f() await-for-promise(p) 호출하면 대신 p 가 해결된 후 실행을 재개하는 새 Promise를 반환합니다. 실행이 완료된 후 자체적으로 해결됩니다(또는 await-for-promise 를 다시 호출). await-for-promise 에 대한 호출이 여러 promise-on-await 컨텍스트 내에서 이루어지면 가장 최근의 것이 Promise를 반환합니다. await-for-promise promise-on-await 외부에서 이루어지면 나쁜 일이 발생합니다(인스턴스의 start 코드가 await 를 실행하는 것과 같음).

말이 돼?

@RossTate 그것은 아주 가깝고, 예, 일반적인 아이디어를 포착합니다. (그러나 당신이 말했듯이, 이것을 폴리필하는 데 사용할 수 없고 특정 wasm/JS 경계 처리가 없기 때문에 거의 동등합니다.)

해당 텍스트를 수정하도록 제안해 주셔서 감사합니다. 나는 여기에 토론에서 그러한 메모 목록을 보관하고 있습니다. (시간이 지남에 따라 변경하지 않는 것이 덜 혼란스러워 보이기 때문에 첫 번째 게시물에 적용할 가치가 있는지 잘 모르겠습니다.)

@RossTate 재미있네요... 좋아요! 호출의 비동기 특성을 명시적으로 만들고(잠재적으로 비동기 호출에는 promise-on-await 가 필요함) Wasm을 변경할 필요가 없습니다. 또한 중간에서 Wasm을 제거하면 의미가 있습니다 promise-on-await 가 await-for-promise 를 직접 호출하면 Promise 를 반환합니다.

@kripken 이것이 다른 이유에 대해 더 자세히 설명할 수 있습니까? 왜 Wasm/JS 경계가 여기서 중요한지 잘 이해가 되지 않습니다.

@binji 난 그냥 JS의 그러한 기능이 wass가 비슷한 일을 하도록 내버려 두지 않는다는 것을 의미했습니다. wasm에서 가져오기로 호출하면 작동하지 않습니다. 우리는 여전히 재개 가능한 방식으로 경계 등으로 was를 빠져나갈 방법이 필요하지 않습니까?

@kripken 맞습니다. 그 시점에서 await-for-promise import는 Wasm 내장처럼 작동해야 합니다.

내 생각은 wasm에 await 명령을 추가하는 대신 이러한 모듈이 대신 await-for-promise 를 가져와 호출한다는 것입니다. 유사하게, 내보낸 함수를 변경하는 대신 JS 코드는 promise-on-await 내에서 함수를 호출합니다. 이것은 JS 프리미티브가 WebAssembly 스택을 포함한 모든 스택 작업을 처리한다는 것을 의미합니다. 또한 더 유연할 것입니다. 예를 들어 원하는 경우 모듈에 다시 호출할 수 있는 JS 콜백을 제공하고 내부 절 대신 외부 호출 일시 중지를 가질 수 있습니다. 모든 것은 JS 코드가 선택하는지 여부에 따라 다릅니다. promise-on-await 로 호출을 래핑할지 여부를 지정합니다. wasm 자체를 변경할 필요는 없다고 생각합니다.

@syg 가 이러한 잠재적인 JS 기본 요소에 대해 어떻게 생각하는지 듣고 싶습니다.

아, 죄송합니다. @RossTate님 의 의견을 "이해를 확실히 하기 위해 이렇게 바꿔서 올바른 형태인지 알려주세요"로 받아들였으며 구체적인 제안은 아닙니다.

생각해보면 당신의 아이디어는 JS 프레임뿐만 아니라 wasm도 일시 중지하고 싶어하지만 호스트/브라우저 프레임도 있습니다. (현재 제안은 wasm이 호출된 경계까지만 작업함으로써 이를 방지합니다.) 다음은 예입니다.

myList.forEach((item) => {
  .. call something which ends up pausing ..
});

forEach 가 브라우저 코드에 구현되어 있으면 브라우저 프레임을 일시 중지한다는 의미입니다. 또한 중요한 것은 이러한 루프의 중간에 일시 중지했다가 나중에 다시 시작하는 것이 JS가 할 수 있는 새로운 능력이 될 것이며 귀하의 아이디어는 일반 루프에서도 이를 허용한다는 것입니다.

for (let i of something) {
  .. call something which ends up pausing ..
}

그리고 이 모든 것이 async JS 함수와 스펙상 상호작용을 일으킬 수 있습니다. 이것들은 모두 브라우저와 JS 사람들과 함께 하기에는 큰 토론처럼 보입니다.

그러나 이것은 또한 await 및 waitref 를 코어 wasm 사양에 추가하는 것을 방지할 뿐이지만, 코어 사양에서는 아무것도 하지 않기 때문에 작은 추가 사항입니다. 현재 제안은 이미 JS 측에서 복잡성의 99%를 가지고 있습니다. 그리고 IIUC 귀하의 제안은 wasm 사양에 대한 작은 추가 사항과 JS 측의 훨씬 더 큰 추가 사항을 상쇄합니다. 따라서 이것은 웹 플랫폼을 전체적으로 더 복잡하게 만들고 이것이 모두 wasm을 위한 것이기 때문에 불필요하게 만듭니다. 또한 코어 wasm 사양에서 await 를 정의하면 실제로 웹 외부에서 유용할 수 있는 이점이 있습니다.

귀하의 제안에서 누락된 것이 있을 수 있습니다. 그렇다면 사과드립니다. 전반적으로, 코어 wasm 사양에 추가를 피하려는 동기가 무엇인지 궁금합니다.

나는 그 프리미티브가 js에 대해 별로 의미가 없다고 생각하고, 브라우저에 있는 것보다 더 많은 wasm 구현이 이점을 얻을 수 있다고 생각합니다. 재개 가능한 예외(대략 효과)가 이 사용 사례를 충족하지 못하는 이유가 여전히 궁금합니다.

내 의견은 둘 다의 조합이었습니다. 높은 수준에서 저는 제안을 순전히 JS API의 강화로 바꿀 수 있는 방법이 있는지 알아 내려고 노력하고 있습니다(그리고 유사하게 다른 호스트가 wasm 모듈과 상호 작용하는 방식). 이 연습은 wasm이 정말로 변경되어야 하는지 여부를 평가하는 데 도움이 되며 실제로 제안이 JS 사람들이 승인할 수도 있고 승인하지 않을 수도 있는 새로운 기본 요소를 JS에 비밀리에 추가하는지 판단하는 데 도움이 됩니다. 즉, 가져온 await : func (param externref) (result externref) 만으로 할 수 없다면 이것이 JS에 새로운 기능을 추가하는 것일 가능성이 큽니다.

wasm에 대한 변경의 단순성에 관해서는 모듈 간 호출에 대해 수행할 작업, 내보낸 함수가 await 를 실행할 수 있는 함수에 대한 포인터가 포함된 GC 값을 반환할 때 수행할 작업과 같이 여전히 고려해야 할 사항이 많이 있습니다. 통화가 끝난 후 등등.

연습으로 돌아가서 지적한 대로 wasm 스택만 캡처해야 하는 좋은 이유가 있습니다. 이것은 약간의 새로운 관점으로 약간 수정되었지만 이전의 제안으로 돌아가게 합니다. JS API에 WebAssembly.instantiateAsync(moduleBytes, imports, "name1", "name2") 함수를 추가합니다. moduleBytes 에 여러 가져오기와 추가 가져오기 import "name1" "name2" (func (param externref) (result externref)) 가 있다고 가정합니다. 그런 다음 instantiateAsync 는 imports 에 의해 제공된 값으로 moduleBytes $ 의 다른 가져오기를 인스턴스화하고 개념적으로 await-for-promise 인 추가 가져오기를 인스턴스화합니다. 내보낸 함수가 이 인스턴스에서 생성되면 보호되어(개념적으로 promise-on-await 에 의해) 이 await-for-promise 가 호출될 때 스택을 올라가 첫 번째 보호를 찾은 다음 내용을 복사합니다. 스택을 새 Promise에 넣은 다음 즉시 반환합니다. 이제 위에서 언급한 것과 동일한 기본 요소가 있지만 더 이상 일급이 아니며 이 제한된 패턴으로 인해 wasm 스택만 캡처될 수 있습니다. 동시에 WebAssembly는 패턴을 지원하기 위해 변경할 필요가 없습니다.

생각?

@devsnek

재개 가능한 예외(대략 효과)가 이 사용 사례를 충족하지 못하는 이유가 여전히 궁금합니다.

그들은 확실히 이 공간의 옵션입니다.

@rossberg 의 마지막 프레젠테이션 에서 내가 이해한 것은 그가 처음에는 그 길을 가고 싶었지만 코루틴 접근 방식을 하기 위해 방향을 바꿨다는 것입니다. "문제"라는 제목의 슬라이드를 참조하십시오. 그 슬라이드 후에 이 공간의 또 다른 옵션인 코루틴에 대해 설명합니다. 그래서 아마도 당신의 질문은 @rosberg 에 대한 것입니다. 누가 명확히 할 수 있습니까?

이 제안은 재개 가능한 예외 또는 코루틴만큼 많은 전력이 필요하지 않은 동기화/비동기 문제를 해결하는 데 중점을 둡니다. 그것들은 wasm 모듈 내부의 내부 상호 작용에 초점을 맞추는 반면 우리는 wasm 모듈과 외부 간의 상호 작용에 초점을 맞춥니다(동기화/비동기 문제가 발생하는 곳이기 때문에). 이것이 우리가 핵심 wasm 사양에서 하나의 새로운 명령만 필요로 하는 이유이며 이 제안의 거의 모든 논리는 wasm JS 사양에 있습니다. 그리고 이것은 다음과 같이 Promise를 기다릴 수 있음을 의미합니다.

call $get_promise
await
;; use it!

wasm의 단순함은 그 자체로 유용하지만 VM이 어떤 일이 진행되고 있는지도 매우 명확하다는 것을 의미합니다.

@RossTate

즉, 가져온 await : func (param externref) (result externref)만으로 할 수 없다면 이것이 JS에 새로운 기능을 추가하는 것일 가능성이 큽니다.

나는 그 추론을 따르지 않습니다, 죄송합니다. 그러나 그것은 나에게 회전하는 것처럼 보입니다. 이 제안이 JS에 새로운 기능을 추가한다고 생각한다면 직접 보여주지 않겠습니까? (그렇지 않다고 굳게 믿고 있지만, 우리가 실수한 것을 발견하면 궁금합니다!)

wasm에 대한 변경 사항의 단순성에 관해서는 모듈 간 호출에 대해 수행할 작업과 같이 여전히 고려해야 할 사항이 많이 있습니다.

코어 wasm 사양 에서 모듈 간 호출에 대해 언급합니까? 나는 그것이 그렇게했는지 기억하지 못하고 관련 섹션 을 훑어보고 이제는 그것을 볼 수 없습니다. 하지만 내가 뭔가를 놓친 것은 아닐까?

내 생각에 핵심 wasm 사양 추가는 기본적으로 await 를 나열하는 것이며 "무언가를 기다리기" 위한 것이며 그게 전부입니다. 그래서 제안서에 That's it for the core wasm spec! 라고 썼습니다. 내가 틀렸다면 더 추가해야 할 핵심 wasm 사양을 보여주세요.

언젠가 핵심 wasm 사양에 wasm 모듈을 생성하고 그에 대한 메소드를 호출하는 새로운 명령이 있을 것이라고 추측하고 말합시다. 이 경우 await 는 단지 트랩이라고 말할 것입니다. 왜냐하면 그것의 요점은 호스트에서 외부의 무언가를 기다리는 것이기 때문입니다.

이것은 약간의 새로운 관점[새로운 아이디어]으로 약간 수정되었지만 이전의 제안으로 돌아가게 합니다.

그 아이디어는 제안서의 Alternative approaches considered 에 있는 두 번째 단락과 기능적으로 동일하지 않습니까? 그런 것도 할 수 있지만 우리는 그것이 덜 좋다고 생각하는 이유를 설명했습니다.

@kripken 알았 습니다. 분명히 await 는 매우 실용적이고 우아한 방식으로 제시된 사용 사례를 해결한다고 생각합니다. 나는 또한 우리가 이 모멘텀을 사용하여 디자인을 약간 확장하여 다른 사용 사례도 해결할 수 있기를 희망합니다.

@RossTate 의 제안은 실제로 "대체 접근 방식 고려"에서 언급한 것과 매우 흡사하다고 생각합니다. 그래서 그 접근이 기각된 이유에 대해 더 자세히 논의해야 한다고 생각합니다. JS 쪽을 작동 가능하게 만들 수 있다면 wasm 사양 변경이 없는 솔루션이 더 바람직하다는 데 우리 모두 동의할 수 있다고 생각합니다. 나는 당신이 그 섹션에서 제시한 단점과 그것이 JS 전용 솔루션을 그렇게 받아들일 수 없게 만드는 이유를 이해하려고 노력하고 있습니다.

wasm 사양 변경이 없는 솔루션이 바람직하다는 데 우리 모두 동의할 수 있다고 생각합니다.

아니요! 여기에서 논의된 비 웹 사용 사례를 참조하십시오. wasm 사양에 await 가 없으면 각 플랫폼에서 임시로 작업을 수행하게 됩니다. JS 환경은 일부 가져오기 작업을 수행하고 다른 곳에서는 "동기식"으로 표시된 새 API를 생성하는 등의 작업을 수행합니다. wasm 생태계는 일관성이 떨어지고 웹에서 다른 곳으로 wasm을 옮기는 것이 더 어려울 것입니다.

하지만 네, 코어 was spec 부분을 가능한 한 간단하게 만들어야 합니다. 내 생각에 이것이 그렇게 합니까? 논리의 99%가 JS 측에 있습니다(그러나 @RossTate 는 동의하지 않는 것으로 보이며 우리는 여전히 그것을 알아내려고 노력하고 있습니다. 나는 마지막 응답에서 상황을 발전시키기를 바라는 구체적인 질문을 했습니다).

내 생각에 핵심 wasm 사양 추가는 기본적으로 await 를 나열하는 것이며 "무언가를 기다리기" 위한 것이며 그게 전부입니다.

이러한 의미 체계를 보다 정확하게 공식화할 수 없는 경우 사양에 모호성 또는 구현 정의 동작이 도입됩니다. 우리는 지금까지 (SIMD의 경우 상당한 비용으로) 그것을 피했으므로 이것이 확실히 고정되기를 바라는 것입니다. 나는 제안서 자체가 이것을 더 형식적으로 만들기 위해 변경되어야 한다고 생각하지 않지만, "무언가를 기다리다"는 사양에서 이미 사용하고 있는 정확한 용어로 고쳐 써야 합니다.

코어 wasm 사양에서 모듈 간 호출에 대해 언급합니까?

인스턴스의 가져오기는 다른 인스턴스의 내보내기로 인스턴스화할 수 있습니다. JS API(그리고 wasm의 구성 원칙)에 대해 내가 이해한 바에 따르면 이러한 가져오기에 대한 호출은 개념적으로 다른 인스턴스가 내보낸 함수에 대한 직접 호출입니다. 두 인스턴스 간에 전달되는 funcref 와 같은 기능 값에 대한 (간접) 호출도 마찬가지입니다.

언젠가 핵심 wasm 사양에 wasm 모듈을 생성하고 그에 대한 메소드를 호출하는 새로운 명령이 있을 것이라고 추측하고 말합시다. 이 경우 외부에서, 호스트에서 무언가를 기다리는 것이 요점이기 때문에 await just trap이라고 말할 수 있을 것 같습니다.

대면 회의에서 논의된 모듈 구성 원칙에 따라 트랩되지 않아야 합니다. 마치 하나의 (구성된) 모듈 인스턴스가 있고 await 를 실행한 것처럼 해야 합니다. 즉, await 는 스택을 가장 최근의 JS 스택 프레임까지 압축합니다.

이것은 f 가 일부 wasm 인스턴스의 내보낸 단항 함수의 값인 경우 instanceization-parameters 개체 {"some" : {"import" : f}} 가 {"some" : {"import" : (x) => f(x)}} 와 의미적으로 다릅니다. 전자에 대한 호출은 wasm 스택 내에 유지되는 반면 후자에 대한 호출은 간신히라도 JS 스택에 들어갑니다. 지금까지 이러한 인스턴스화 매개변수 개체는 동등한 것으로 간주됩니다. 코드 마이그레이션/언어 상호 운용성 관점에서 이것이 유용한 이유에 대해 설명할 수 있지만, 현재로서는 여담입니다.

그 아이디어는 제안에서 고려된 대안적 접근의 두 번째 단락과 기능적으로 동일하지 않습니까? 그런 것도 할 수 있지만 우리는 그것이 덜 좋다고 생각하는 이유를 설명했습니다.

죄송합니다. 저는 그 대안을 다른 의미로 읽었지만 제 혼란을 설명하는 것 외에는 중요하지 않습니다. 제 제안과 같은 의미로 말씀하신 것 같습니다. 이 경우 찬반 양론을 논의할 가치가 있습니다.

이 제안이 wasm 측면에서 매우 가볍다는 사실은 await 명령이 가져온 함수에 대한 호출과 의미상 동일해 보이기 때문입니다. 물론, 당신이 지적한 것처럼 관습 이 중요합니다! 그러나 await 가 이것이 유지되는 유일한 기능은 아닙니다. 대부분의 가져온 함수에 대해서도 마찬가지입니다. await 의 경우 이 기능이 있는 모듈에 import "control" "await" (func (param externref) (result externref)) 절이 있고 이 기능을 지원하는 환경에서 항상 해당 가져오기를 인스턴스화하여 관례에 대한 우려를 해결할 수 있다고 생각합니다. 적절한 콜백으로.

그것은 당신이 찾고 있는 크로스 플랫폼 이식성을 여전히 제공하면서 wasm을 변경하지 않음으로써 많은 작업을 절약하는 솔루션을 제공하는 것 같습니다. 그러나 나는 여전히 제안의 뉘앙스를 이해하기 위해 노력하고 있으며 지금까지 이미 많은 것을 놓쳤습니다!

이 제안이 wasm 측면에서 매우 가볍다는 사실은 await 명령이 가져온 함수에 대한 호출과 의미상 동일하게 보이기 때문입니다.

FWIW는 이 제안이 원래 시작된 곳이지만 이와 같은 내장 기능을 사용하는 것은 VM에 더 불투명하고 일반적으로 권장되지 않습니다( @binji 는 원래 토론에서 이 제안에서 멀어질 것을 제안했다고 생각합니다).

예를 들어, 귀하의 주장에 따라 memory.grow 또는 atomic.wait 와 같은 것은 상응하게 import "control" "memory_grow" 또는 import "control" "atomic_wait" 로 수행될 수도 있지만 실제로는 그렇지 않습니다. 실제 지침과 동일한 수준의 interop 및 정적 분석 기회(VM 및 도구 측면 모두에서)를 제공하지 않습니다.

memory.grow 명령이 메모리를 내보내지 않는 경우에 여전히 유용하다고 주장할 수 있지만 atomic.wait 는 확실히 코어 외부에서 구현될 수 있습니다. 실제로 await 와 매우 유사합니다. 일시 중지/재개가 발생하는 수준과 await 함수가 atomic.wait 보다 훨씬 더 많은 마법을 필요로 한다는 점을 제외하고는 VM 스택과 상호 작용할 수 있어야 하고 값이 변경될 때까지 현재 스레드를 차단할 수 있어야 하기 때문입니다.

@tlively

"wait for something"은 이미 사양에서 사용되는 정확한 용어로 바꿔야 합니다.

분명하게 예입니다. 도움이 된다면 지금 더 구체적인 텍스트를 제안할 수 있습니다.

When an await instruction is executed on a waitref, the host environment is requested to do some work. Typically there would be a natural meaning to what that work is based on what a waitref is on a specific host (in particular, waiting for some form of host event), but from the wasm module's point of view, the semantics of an await are similar to a call to an imported host function, that is: we don't know exactly what the host will do, but at least expect to give it certain types and receive certain results; after the instruction executes, global state (the store) may change; and an exception may be thrown.

The behavior of an await from the host's perspective may be very different, however, from a call to an imported host function, and might involve something like pausing and resuming the wasm module. It is for this reason that this instruction is defined. For the instruction to be usable on a particlar host, the host would need to define the proper behavior.

Btw, 이것을 작성하는 동안 나에게 온 또 다른 비교는 로드 및 저장에 대한 정렬 힌트입니다. Wasm은 정렬되지 않은 로드 및 저장을 지원하므로 힌트는 wasm 모듈에서 관찰할 수 있는 다른 동작으로 이어질 수 없지만(힌트가 잘못된 경우에도) 호스트의 경우 특정 플랫폼에서 매우 다른 구현을 제안합니다(더 효율적일 수 있음). 따라서 사양에서 The alignment in load and store instructions does not affect the semantics 에서 알 수 있듯이 내부적으로 관찰할 수 있는 다른 의미가 없는 다른 명령어의 예입니다.

@RossTate

대면 회의에서 논의된 모듈 구성 원칙에 따라 트랩되지 않아야 합니다. 마치 하나의 (구성된) 모듈 인스턴스가 있고 await가 실행된 것처럼 해야 합니다. 즉, await는 스택을 가장 최근의 JS 스택 프레임까지 압축합니다.

잘 들렸고 알게 되어서 좋았습니다. 감사합니다. 그 부분을 놓쳤습니다.

나는 이것이 우리의 오해의 일부를 설명한다고 생각합니다. Module => 모듈 호출은 이전에 제 요점이었던 wasm spec atm에 없습니다. 그러나 당신은 그들이 있을 수 있는 미래의 사양에 대해 생각하고 있는 것처럼 들립니다. 어쨌든, 구성성은 그 상황에서 await가 어떻게 행동해야 하는지를 정확히 결정하기 때문에 여기에서는 문제처럼 보이지 않습니다.

코어 wasm 사양에서 모듈 간 호출에 대해 언급합니까? 나는 그것이 그렇게했는지 기억하지 못하고 관련 섹션을 훑어보고 이제는 그것을 볼 수 없습니다. 하지만 내가 뭔가를 놓친 것은 아닐까?

예, 핵심 wasm 사양은 다른 wasm 모듈에서 가져온 기능과 호스트 기능을 구분합니다(§ 4.2.6). 함수 호출의 의미(§ 4.4.7)는 함수를 정의한 모듈에 의존하지 않으며 특히 모듈 간 함수 호출은 현재 동일한 모듈 함수 호출과 동일하게 동작하도록 지정됩니다.

교차 모듈 호출 아래의 await s가 트랩으로 정의된 경우 호스트의 호출에 의해 생성된 마지막 더미 프레임 이전에 교차 모듈 호출이 존재하는지 여부를 검사하기 위해 호출 스택 위로 순회를 지정해야 합니다. (§ 4.5.5). 이것은 사양에서 불행한 합병증이 될 것입니다. 그러나 나는 Ross의 말에 동의합니다. 크로스 모듈 호출 트랩은 구성성을 위반하는 것이므로 전체 스택이 호스트의 마지막 호출로 다시 고정되는 의미 체계를 선호합니다. await 를 호스트 함수 호출(§ 4.4.7.3)과 유사하게 만드는 가장 간단한 사양 지정 방법은 @kripken이라고 합니다. 그러나 호스트 함수 호출은 완전히 비결정적이므로 핵심 사양 관점에서 명령어에 대한 더 나은 이름은 undefined 일 수 있습니다. 그리고 이 시점에서 저는 코어 사양 자체가 undefined 명령어 IMO의 이점을 얻지 못하기 때문에 웹 플랫폼(및 이식성을 위한 WASI)에서 항상 제공되는 본질적인 가져오기를 선호하기 시작합니다.

의미적으로 waitref 와 await 를 반환하는 호스트 환경에 대한 호출은 차단 호출일 뿐입니다.

이것은 브라우저와 같은 비동기 환경이 없고 ​​기본적으로 차단 호출을 지원할 수 있는 웹이 아닌 임베딩에 어떤 가치를 제공합니까?

@RReverser , 나는 당신이 내장에 대해 말하고 있는 요점을 봅니다. 해석되지 않은 기능 대 명령을 통해 작업을 정의해야 하는 시기를 결정하는 것과 관련된 판단 호출이 있습니다. 이 판단의 한 가지 요소는 다른 명령과 상호 작용하는 방식을 고려하는 것입니다. memory.grow 는 다른 메모리 명령어의 동작에 영향을 줍니다. 스레드 제안을 자세히 살펴볼 기회가 없었지만 atomic.wait 가 다른 동기화 명령의 동작에 영향을 미치거나 영향을 받는다고 생각합니다. 그런 다음 사양을 업데이트하여 이러한 상호 작용을 공식화해야 합니다.

그러나 await 자체를 사용하면 다른 명령과의 상호 작용이 없습니다. 유일한 상호 작용은 호스트와의 상호 작용이므로 내 직관은 이 제안이 가져온 호스트 기능을 통해 수행되어야 한다는 것입니다.

atomic.wait 와 이 제안된 await 의 큰 차이점은 $#$2 atomic.wait #$ 로 모듈을 다시 입력할 수 없다는 것입니다. 에이전트가 완전히 일시 중지되었습니다.

@kripken :

@rossberg 의 마지막 프레젠테이션에서 내가 이해한 것은 그가 처음에는 그 길을 가고 싶었지만 코루틴 접근 방식을 하기 위해 방향을 바꿨다는 것입니다. "문제"라는 제목의 슬라이드를 참조하십시오. 그 슬라이드 후에 이 공간의 또 다른 옵션인 코루틴에 대해 설명합니다. 그래서 아마도 당신의 질문은 @rosberg 에 대한 것입니다. 누가 명확히 할 수 있습니까?

예, 따라서 코루틴식 인수분해는 이전의 재개 가능한 예외 설계의 일반화로 생각할 수 있습니다. 재개 가능한 이벤트/예외에 대한 동일한 개념이 있지만 try 명령어는 더 작은 기본 요소로 분해되어 의미 체계가 더 단순해지고 비용 모델이 더 명확해집니다. 또한 다소 표현력이 뛰어납니다.

여전히 의도는 이것이 모든 관련 제어 추상화를 표현할 수 있다는 것이며 비동기는 동기를 부여하는 사용 사례 중 하나입니다. JS 비동기와 상호 운용하기 위해 JS API는 아마도 Wasm 모듈이 가져올 수 있고 일시 중단할 throw 인 미리 정의된 await 이벤트(JS promise를 externref로 전달)를 제공할 수 있습니다. 물론 구체화해야 할 세부 사항이 많이 있지만 원칙적으로는 가능해야 합니다.

현재 제안에 관해서는, 나는 여전히 그것에 대해 머리를 싸매려고 노력하고 있습니다. :)

특히, 이전 Wasm 함수에서 await 를 허용하는 것 같습니다. 올바르게 읽고 있습니까? 그렇다면 비동기 함수에서만 await 를 허용하는 JS와 매우 다릅니다. 그리고 이것은 엔진이 단일(비동기) 함수의 _local_ 변환을 통해 await 를 컴파일할 수 있도록 하기 때문에 매우 핵심적인 제약입니다!

이 제약 조건이 없으면 엔진은 _global_ 프로그램 변환을 수행해야 합니다(Asyncify가 수행하는 것처럼). 여기서 모든 호출은 잠재적으로 훨씬 더 비쌉니다(일부 호출이 await에 도달할지 여부를 일반적으로 알 수 없음). 또는 동등하게 엔진이 여러 스택을 생성하고 스택 간에 전환할 수 있어야 합니다!

이제 이것이 바로 코루틴/효과 처리기 아이디어가 Wasm에 도입하려는 기능입니다. 그러나 분명히 이것은 플랫폼과 그 실행 모델에 대한 매우 사소하지 않은 추가 사항이며 JS가 제어 추상화(예: 비동기 및 생성기)를 피하기 위해 매우 조심해 온 합병증입니다.

@rossberg

특히, 이전 Wasm 함수에서 대기를 허용하는 것 같습니다. 올바르게 읽고 있습니까? 그렇다면 비동기 함수에서만 await를 허용하는 JS와 매우 다릅니다.

예, 여기 모델은 매우 다릅니다. JS await는 기능에 의한 것이지만 이 제안은 전체 wasm 인스턴스의 await를 수행합니다(목표는 JS와 wasm 사이에 있는 JS와 wasm 간의 동기화/비동기 불일치를 해결하는 것이기 때문입니다). 또한 JS await는 손으로 쓴 코드용이며 컴파일된 코드의 이식을 가능하게 합니다.

그리고 이것은 엔진이 단일(비동기) 함수의 로컬 변환을 기다리고 컴파일할 수 있게 하기 때문에 매우 핵심적인 제약입니다! 해당 제약 조건이 없으면 엔진은 모든 호출이 잠재적으로 훨씬 더 비쌀 수 있는 전역 프로그램 변환(Asyncify가 수행하는 것처럼)을 수행해야 합니다(일부 호출이 await에 도달할지 여부를 일반적으로 알 수 없음). 또는 동등하게 엔진이 여러 스택을 생성하고 스택 간에 전환할 수 있어야 합니다!

확실히 글로벌 프로그램 변환은 여기에서 의도된 것이 아닙니다! 명확하지 않은 경우 죄송합니다.

제안서에서 언급했듯이 스택 간 전환은 가능한 구현 옵션 중 하나이지만 코루틴 스타일 스택 전환과 동일하지 않습니다.

• 전체 wasm 인스턴스만 일시 중지할 수 있습니다. 이것은 모듈 내부의 스택 전환을 위한 것이 아닙니다. (특히 이것이 이 제안이 핵심 wasm 사양에 추가되지 않고 전적으로 wasm JS 측에 있을 수 있는 이유입니다. 지금까지 일부 사람들은 그것을 선호하고 어느 쪽이든 효과가 있을 수 있다고 생각합니다.)
• 코루틴은 스택을 명시적으로 선언하지만 await는 그렇지 않습니다.
• await 스택은 한 번만 재개할 수 있으며 두 번 이상 분기/반환이 없습니다(제안에 포함할지 여부가 확실하지 않음).
• 성능 모델은 여기에서 매우 다릅니다. await는 이미 최소한의 오버헤드 및 대기 시간이 있는 JS의 약속을 기다립니다. 따라서 실제로 일시 중지할 때 구현에 약간의 오버헤드가 있고 코루틴보다 덜 신경쓰더라도 괜찮습니다.

이러한 요소와 이 제안의 관찰 가능한 동작이 전체 wasm 인스턴스가 일시 중지된다는 점을 감안할 때 이를 구현하는 다양한 방법이 있을 수 있습니다. 예를 들어, 단일 wasm 인스턴스를 실행하는 VM의 웹 밖에서는 wasm을 재개할 때까지 말 그대로 이벤트 루프를 실행할 수 있습니다. 웹에서 구현 방법 중 하나는 다음과 같습니다. await가 발생하면 현재 위치에서 wasm을 호출한 위치로 전체 wasm 스택을 복사합니다. 옆에 저장하십시오. 다시 시작하려면 다시 복사하고 거기에서 계속 진행하십시오. 이에 대한 다른 접근 방식이나 변형 이 있을 수도 있습니다(일부는 복사하지 않을 수도 있지만 복사 오버헤드를 피하는 것은 실제로 여기서 중요하지 않습니다!).

긴 게시물과 제안 텍스트 자체의 일부 반복에 대해 죄송합니다. 하지만 이것이 귀하가 언급한 요점 중 일부를 명확히 하는 데 도움이 되기를 바랍니다.

구현과 관련하여 여기에서 논의할 것이 많다고 생각합니다. 지금까지 Lucet 에 대한 @acfoltzer의 코멘트는 고무적입니다!

@kripken 의 가장 최근 댓글에서 일부 표현을 명확히 하기 위해 일시 ​​중지되는 것은 전체 wasm 인스턴스가 아닙니다. 일시 중지된 스택의 wasm에 대한 호스트 프레임의 가장 최근 호출일 뿐입니다. 그러면 호스트 프레임이 대신 해당 약속(또는 호스트에 대한 적절한 아날로그)을 반환합니다. 관련 이전 설명은 여기 를 참조하십시오.

흠, 그게 어떻게 차이가 나는지 모르겠습니다. Wasm 내부 깊숙한 곳에서 기다릴 때 적어도 호스트 항목에서 해당 지점까지의 모든 호출 스택을 캡처해야 합니다. 그리고 위에서 다른 호출을 하거나 더 많은 일시 중단을 만드는 동안 해당 일시 중단(즉, 해당 스택 세그먼트)을 원하는 기간 동안 유지할 수 있습니다. 그리고 다른 곳에서 다시 시작할 수 있습니다(제 생각에는?). 구분된 연속의 모든 구현 기계가 필요하지 않습니까? 프롬프트가 별도의 구성이 아닌 Wasm 입력 시 설정된다는 것뿐입니다.

@rossberg

일부 VM에서는 사실일 수 있습니다. await 및 코루틴이 똑같은 VM 작업을 필요로 하는 경우 최소한 추가 작업은 필요하지 않습니다. 이 경우 await 제안의 이점은 편리한 JS 통합이 될 것입니다.

모듈 재입력을 허용하지 않으면 전체 프로그램 변환 없이 편리한 JS 통합을 얻을 수 있다고 생각합니다.

모듈 재입력을 허용하지 않으면 전체 프로그램 변환 없이 편리한 JS 통합을 얻을 수 있다고 생각합니다.

이것은 완료하는 더 쉬운 방법으로 들리지만 호출 스택(또는 첫 번째 단계로 모든 WebAssembly 모듈)에서 방문한 모든 모듈을 차단해야 합니다.

이것은 완료하는 더 쉬운 방법으로 들리지만 호출 스택(또는 첫 번째 단계로 모든 WebAssembly 모듈)에서 방문한 모든 모듈을 차단해야 합니다.

atomic.wait 처럼 맞습니다.

@taralx

모듈 재입력을 허용하지 않으면 전체 프로그램 변환 없이 편리한 JS 통합을 얻을 수 있다고 생각합니다.

한편으로는 재진입이 유용할 수 있습니다. 예를 들어 게임 엔진이 파일을 다운로드할 수 있으며 그렇게 하는 동안 UI가 완전히 일시 중지되는 것을 원하지 않을 수 있습니다(Asyncify에서는 현재 허용). 그러나 다른 한편으로는 재진입이 허용되지 않을 수 있지만 응용 프로그램이 이에 대해 동일한 모듈의 여러 인스턴스를 생성할 수 있으므로(모두 동일한 메모리, 변경 가능한 전역 등을 가져오는가?), 따라서 재진입은 호출이 될 것입니다. 다른 인스턴스로. 나는 우리가 도구 체인에서 그 작업을 수행할 수 있다고 생각합니다.

따라서 단순화가 VM에 도움이 된다면 확실히 고려해 볼 가치가 있습니다!

(앞서 논의한 바와 같이 여기에서 논의 중인 옵션 중 하나와 함께 전체 프로그램 변환이 필요하다고 생각하지 않는다는 점에 유의하십시오. Asyncify가 있는 나쁜 상황에 있는 경우에만 필요합니다. 도구 체인 수준. 기다리기 위해 @rossberg 와 논의한 최악의 경우 코루틴 제안이 내부적으로 수행할 작업을 수행할 수 있습니다. 그러나 작업을 더 간단하게 만들면 아이디어가 잠재적으로 매우 흥미로울 수 있습니다!)

한편으로는 재진입이 유용할 수 있습니다. 예를 들어 게임 엔진이 파일을 다운로드할 수 있으며 그렇게 하는 동안 UI가 완전히 일시 중지되는 것을 원하지 않을 수 있습니다(Asyncify에서는 현재 허용).

그러나 이것이 사운드 기능인지 확실하지 않습니다. 그러나 이것이 응용 프로그램에 _예기치 않은 동시성_을 도입할 것 같습니다. 렌더링하는 동안 자산을 ​​로드하는 기본 애플리케이션은 내부적으로 2개의 스레드를 사용하고 각 스레드는 WebWorker + SharedArrayBuffer에 매핑됩니다. 응용 프로그램이 스레드를 사용하는 경우 WebWorkers의 동기 웹 기본 요소도 사용할 수 있습니다(적어도 일부 경우에는 허용됨). 그렇지 않으면 Atomics.wait(예:)를 사용하여 기본 스레드의 비동기 작업을 작업자의 차단 작업에 매핑하는 것이 항상 가능합니다.

전체 사용 사례가 일반적으로 멀티스레딩으로 이미 해결되지 않았는지 궁금합니다. 작업자에서 차단 프리미티브를 사용함으로써 전체 스택(JS/Wasm/browser 기본)이 보존되어 훨씬 간단하고 강력해 보입니다.

작업자에서 차단 프리미티브를 사용함으로써 전체 스택(JS/Wasm/browser 기본)이 보존되어 훨씬 간단하고 강력해 보입니다.

이것은 실제로 내가 실험한 독립 실행형 Asyncify JS 래퍼의 또 다른 대안 구현이지만, 코드 크기 문제를 해결하는 동안 성능 오버헤드는 Wasm 변환을 사용하는 현재 Asyncify보다 훨씬 더 높았습니다.

@alexp-sssup

이것은 응용 프로그램에서 예기치 않은 동시성을 도입할 것 같습니다.

물론 그렇습니다. 매우 조심스럽게 수행해야 하며 문제가 발생할 수 있습니다. 우리는 Asyncify를 사용하여 좋은 것과 나쁜 것을 혼합한 경험을 가지고 있습니다(예를 들어 유효한 사용 사례: 파일이 JS로 다운로드되고 JS가 다시 시작하기 전에 파일을 복사할 공간을 malloc하기 위해 wasm을 호출함). 그러나 어쨌든 재진입은 이 제안의 중요한 부분이 아닙니다.

@RReverser 가 말한 것에 덧붙여 스레드에 대한 또 다른 문제는 스레드에 대한 지원이 보편적 이지 않으며 앞으로도 없을 것이라는 점 입니다. 그러나 기다림은 어디에서나 있을 수 있습니다.

async/await가 도입된 다른 언어에서는 재입력이 절대적으로 중요합니다. 하나가 기다리는 동안 다른 이벤트가 발생할 수 있다는 요점의 종류입니다. 재진입이 상당히 중요한 것 같습니다.

또한 모듈이 외부 함수를 호출할 때마다 내보내기를 통해 모듈이 다시 입력될 수 있다고 가정해야 하는 것이 사실이 아닙니까(위의 예에서는 대기 없이도 외부 함수에 대한 호출이 함수는 malloc을 호출하는 데 무료입니다(말장난 없음).

응용 프로그램은 동일한 모듈의 여러 인스턴스를 만들 수 있으므로(모두 동일한 메모리, 변경 가능한 전역 등을 가져오는가?), 따라서 재진입은 다른 인스턴스에 대한 호출이 됩니다.

모듈의 공유 메모리에만 해당됩니다. 다른 메모리는 다시 인스턴스화해야 하며, 이는 한 작업이 진행 중인 변경에서 다른 작업을 스톰프하지 않도록 하는 데 중요합니다.

나는 이것의 비 재진입 버전이 스레드 지원이 포함된 모든 임베딩에서 폴리필이 가능하다는 점에 주목합니다. 누군가가 그것을 가지고 놀고 얼마나 유용한지 알고 싶어할 경우를 대비해서입니다.

나는 이것의 비 재진입 버전이 스레드 지원이 포함된 모든 임베딩에서 폴리필이 가능하다는 점에 주목합니다. 누군가가 그것을 가지고 놀고 얼마나 유용한지 알고 싶어할 경우를 대비해서입니다.

위에서 언급했듯이 그것은 우리가 이미 가지고 놀았지만 현재 솔루션보다 더 나쁜 성능을 가져오고 보편적으로 지원되지 않으며 추가로 WebAssembly.Global 또는 WebAssembly.Table 를 공유하기 매우 어렵기 때문에 폐기되었습니다. 추가 해킹 없이 메인 스레드를 사용하므로 투명한 폴리필에 적합하지 않습니다.

Wasm 모듈을 다시 작성하는 현재 솔루션은 이러한 문제를 겪지 않지만 대신 상당한 파일 크기 비용이 있습니다.

따라서 이들 중 어느 것도 대규모 실제 앱에 적합하지 않으므로 여기에 설명된 것과 같이 비동기식 통합에 대한 기본 지원을 살펴보게 됩니다.

더 나쁜 성능

일종의 벤치마크가 있습니까?

예, 화요일(또는 수요일)에 다시 일할 때 공유할 수 있습니다. 또는 빈 비동기 JS 함수를 직접 호출하는 함수를 작성하는 것은 상당히 쉽습니다.

감사 해요. 마이크로벤치마크를 만들 수는 있지만 그다지 유익하지는 않습니다.

오 예, 우리는 순전히 오버 헤드 비교에 관심이 있었기 때문에 마이크로 벤치 마크입니다.

마이크로벤치마크의 문제는 실제 애플리케이션에서 허용 가능한 대기 시간을 모른다는 것입니다. 추가로 1ms가 걸린다면, 예를 들어 응용 프로그램이 1/s 속도로 대기 작업만 수행하는 경우 실제로 문제가 되는 것입니까?

원자 기반 접근 방식의 속도에 초점을 맞추는 것이 주의를 산만하게 할 수 있다고 생각합니다. 앞에서 언급했듯이 원자는 모든 곳에서 작동하지 않으며(COOP/COEP로 인해) 작동하지 않으며 주 스레드가 차단할 수 없기 때문에 작업자만 원자적 접근 방식을 사용할 수 있습니다. 멋진 생각이지만 보편적인 솔루션을 위해서는 Await와 같은 것이 필요합니다.

나는 그것을 장기적인 해결책으로 제안하지 않습니다. 비 재진입 솔루션이 사람들에게 효과가 있는지 확인하는 데 사용할 수 있는 폴리필을 제안합니다.

@taralx 아, 알겠습니다. 감사합니다.

@taralx :

모듈 재입력을 허용하지 않으면 전체 프로그램 변환 없이 편리한 JS 통합을 얻을 수 있다고 생각합니다.

그것은 나쁠 것입니다. 이는 여러 모듈을 병합하면 동작이 중단될 수 있음을 의미합니다. 그것은 모듈화에 반대되는 것입니다.

일반적인 설계 원칙으로서 작동 동작은 모듈 경계(단순 범위 제외)에 종속되어서는 안 됩니다. 모듈은 Wasm의 그룹화 및 범위 지정 메커니즘일 뿐이며 프로그램의 동작을 변경하지 않고도 항목을 재그룹화하는 기능(모듈 연결/병합/분할)을 유지하기를 원합니다.

@rossberg : 앞서 제안한 대로 모든 Wasm 모듈에 대한 액세스를 차단하는 것으로 일반화할 수 있습니다. 하지만 너무 제한적일 수 있습니다.

그것은 나쁠 것입니다. 이는 여러 모듈을 병합하면 동작이 중단될 수 있음을 의미합니다. 그것은 모듈화에 반대되는 것입니다.

이것이 polyfilling 인수에 대한 제 요점이었습니다 atomic.wait 는 모듈성을 깨뜨리지 않으므로 이것도 마찬가지입니다.

@taralx , atomic.wait 는 특정 메모리의 특정 위치를 참조합니다. await 사용을 차단하는 메모리와 위치는 무엇이며 해당 메모리를 공유하는 모듈을 어떻게 제어합니까?

@rossberg 이것이 깨졌다고 생각하는 시나리오에 대해 자세히 설명해 주시겠습니까? 비 재진입 버전이 작동하는 방식에 대해 서로 다른 아이디어가 있다고 생각합니다.

@taralx , 각각 A.f 및 B.g $ 와 같이 일부 내보내기 기능을 제공하는 두 개의 모듈 A 및 B를 로드하는 것을 고려하십시오. 둘 다 호출될 때 await 를 수행할 수 있습니다. 두 개의 클라이언트 코드가 각각 이러한 함수 중 하나에 전달되고 독립적으로 호출됩니다. 그들은 서로 간섭하거나 차단하지 않습니다. 그런 다음 누군가 코드를 변경하지 않고 A와 B를 C로 병합하거나 리팩토링합니다. 갑자기 두 클라이언트 코드가 예기치 않게 서로를 차단하기 시작할 수 있습니다. 숨겨진 공유 상태를 통해 원거리에서 으스스한 액션.

그것은 의미가 있습니다. 그러나 재진입을 허용하면 예상하지 않은 모듈에서 동시성이 위험하므로 어느 쪽이든 멀리서 보면 으스스한 행동입니다.

하지만 모듈은 이미 재입력이 가능합니다. 그렇죠? 모듈이 가져오기를 호출할 때마다 외부 코드가 모듈에 다시 들어갈 수 있어 반환하기 전에 전역 상태를 변경할 수 있습니다. 제안된 대기 중 재진입이 가져온 함수를 호출하는 것보다 더 으스스하거나 동시적이라는 것을 알 수 없습니다. 내가 뭔가를 놓치고 있는 건 아닐까?

(편집됨)

흠, 네. 좋습니다. 가져온 함수가 모듈에 다시 들어갈 수 있습니다. 나는 분명히 이것에 대해 더 열심히 생각할 필요가 있다.

코드가 실행 중이고 함수를 호출할 때 두 가지 가능성이 있습니다. 함수가 임의의 것을 호출하지 않거나 함수가 임의의 것을 호출할 수 있음을 알고 있습니다. 후자의 경우에는 항상 재입장이 가능합니다. await 에도 동일한 규칙이 적용됩니다.

(위의 내 댓글 수정)

지금까지 토론해 주셔서 감사합니다!

요약하자면, 여기에 일반적인 관심이 있는 것처럼 들리지만 이것이 JS 측에서 100%여야 하는지 아니면 99%여야 하는지와 같은 큰 공개 질문이 있습니다. 웹의 경우에는 괜찮으므로 아마도 괜찮을 것입니다. 또 다른 큰 공개 질문은 더 많은 정보가 필요한 VM에서 이것이 얼마나 실현 가능한가입니다.

저는 2주 후에 다음 CG 회의에서 의제 항목을 제안하여 이 제안을 논의하고 1단계에서 고려할 것입니다. 즉, repo를 열고 별도의 문제에서 열린 질문에 대해 더 자세히 논의하는 것을 의미합니다. (나는 그것이 올바른 과정이라고 생각하지만, 내가 틀렸다면 지적해주세요.)

참고로
우리는 유사한 방식으로 전체 스택 전환 제안을 만들 것입니다.
시간 프레임. 나는 그것이 당신의 특별한 경우 변형을 무의미하게 만들 수 있다고 생각합니다.
어떻게 생각해?
프란시스

2020년 5월 28일 목요일 오후 3시 51분에 Alon Zakai [email protected] 이 작성했습니다.

지금까지 토론해 주셔서 감사합니다!

요약하면 여기에 일반적인 관심이 있는 것처럼 들리지만 여기에는
이것이 JS 측에서 100%이어야 하는지 아니면 그냥
99% - 전자가 일부 사람들의 주요 걱정거리를 제거하는 것처럼 들립니다.
웹의 경우에는 괜찮을 것이므로 아마도 괜찮을 것입니다.
또 다른 큰 미해결 질문은 이것이 VM에서 얼마나 실현 가능한가 하는 것입니다.
에 대해 더 많은 정보가 필요합니다.

2주 후에 논의할 다음 CG 회의의 의제를 제안하겠습니다.
리포지토리를 여는 것을 의미하는 1단계에서 이 제안을 고려합니다.
별도의 문제에서 열린 질문에 대해 더 자세히 논의합니다.
(나는 그것이 올바른 과정이라고 생각하지만, 내가 틀렸다면 지적해주세요.)

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/1345#issuecomment-635649331 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAQAXUCLZ4CJVQYEUBK23BLRT3TFLANCNFSM4NEJW2PQ
.

>

프랜시스 맥케이브
SWE

@fgmccabe

우리는 그것에 대해 확실히 논의해야 합니다.

그러나 일반적으로 귀하의 제안이 JS 측에 초점을 맞추지 않는 한, 이 제안이 문제가 되지 않을 것이라고 생각합니다(JS 측에 99%-100%).

구현 세부 사항에 대한 논의가 끝났으므로, 이전 에 표명했지만 한 번에 하나의 논의를 위해 생략한 상위 수준의 우려 사항을 다시 제기하고 싶습니다.

프로그램은 많은 구성 요소로 구성됩니다. 소프트웨어 엔지니어링 관점에서 구성 요소를 부분으로 분할하거나 구성 요소를 병합해도 프로그램의 동작이 크게 변경되지 않는 것이 중요합니다. 이것이 지난 CG 대면 회의에서 논의된 모듈 구성 원칙의 근거이며 많은 언어의 디자인에 내포되어 있습니다.

웹 프로그램의 경우 이제 WebAssembly를 사용하여 이러한 다른 구성 요소를 JS 또는 wasm과 같은 다른 언어로 작성할 수도 있습니다. 사실, 많은 구성 요소는 어느 언어로도 작성될 수 있습니다. 저는 이것을 "양가적(ambivalent)" 구성요소라고 부를 것입니다. 현재 대부분의 양면적인 구성 요소는 JS로 작성되지만 우리 모두는 점점 더 많은 구성 요소가 wasm으로 다시 작성되기를 희망한다고 상상합니다. 이 "코드 마이그레이션"을 용이하게 하려면 이러한 방식으로 구성 요소를 다시 작성해도 구성 요소가 환경과 상호 작용하는 방식이 변경되지 않도록 해야 합니다. 예를 들어, 특정 "적용" 프로그램 구성요소 (f, x) => f(x) 가 JS로 작성되었는지 또는 wasm으로 작성되었는지 여부는 전체 프로그램의 동작에 영향을 미치지 않아야 합니다. 이것은 코드 마이그레이션 원칙입니다.

불행히도 이 제안의 모든 변형은 모듈 구성 프로그램이나 코드 마이그레이션 원칙을 위반하는 것으로 보입니다. 전자는 await 가 현재 wasm 모듈이 가장 최근에 입력된 위치까지 스택을 캡처할 때 위반됩니다. 이 경계는 모듈이 분리되거나 함께 결합될 때 변경되기 때문입니다. 후자는 await 가 wasm이 가장 최근에 입력된 위치까지 스택을 캡처할 때 위반됩니다. 이 경계는 코드가 JS에서 wasm으로 마이그레이션될 때 변경되기 때문입니다(따라서 (f, x) => f(x) 와 같은 간단한 마이그레이션은 JS to wasm은 전체 프로그램의 동작을 크게 변경할 수 있습니다.

나는 이러한 위반이 이 제안의 잘못된 디자인 선택 때문이라고 생각하지 않습니다. 오히려 문제는 이 제안이 JS를 간접적으로 더 강력하게 만드는 것을 피하려는 것이며, 그 목표는 이러한 원칙을 위반하는 인위적인 경계를 부과하도록 강요하는 것입니다. 나는 그 목표를 완전히 이해하지만 이 문제가 점점 더 많이 나타날 것이라고 생각합니다. 이러한 원칙을 존중하는 방식으로 WebAssembly에 기능을 추가하려면 JS가 임베딩 언어이기 때문에 JS에 기능을 간접적으로 추가해야 하는 경우가 많습니다. 내 선호 사항은 그 문제를 정면으로 해결하는 것입니다(해결 방법을 전혀 모릅니다). 그렇지 않은 경우 나의 두 번째 선호 사항은 JS API에서만 이 변경을 수행하는 것입니다. wasm이 해석할 수 없는 WebAssembly에 지침을 추가하는 대신 JS가 여기에서 제한 요소이기 때문입니다.

나는 이러한 위반이 이 제안의 잘못된 디자인 선택 때문이라고 생각하지 않습니다. 오히려 문제는 이 제안이 JS를 간접적으로 더 강력하게 만드는 것을 피하려는 것 같습니다.

그것이 중요하지만 여기에서 디자인의 주된 이유는 아닙니다.

이 디자인의 주된 이유는 구성 원칙이 wasm 에 대해 의미가 있다는 데 전적으로 동의하지만 웹에서 우리가 가지고 있는 근본적인 문제는 실제로 JS와 wasm이 실제로 동일 하지 않다는 것입니다. 우리는 비동기식으로 필기한 JS와 동기화된 포팅된 wasm을 가지고 있습니다. 다시 말해, 그들 사이의 경계는 실제로 우리가 해결하려는 정확한 문제입니다. 전반적으로 나는 구성 원칙이 wasm과 JS에 적용되어야 한다는 데 동의하는지 잘 모르겠습니다(하지만 아마도 그래야 하고 흥미로운 토론이 될 수 있습니다).

여기에서 공개적으로 더 많은 토론을 하고 싶었지만 시간을 절약하기 위해 지금까지 여기에 참여하는 사람이 거의 없기 때문에 일부 VM 구현자에게 직접 연락했습니다. 여기 토론과 함께 그들의 피드백을 감안할 때 슬프게도 우리는 이 제안을 일시 중지해야 한다고 생각합니다.

Await는 일반 코루틴이나 스택 전환보다 관찰 가능한 동작이 훨씬 더 간단하지만, 내가 이야기한 VM 사람들은 @rossberg 가 결국 VM 작업이 둘 다 비슷할 것이라는 데 동의합니다. 그리고 적어도 일부 VM 사람들은 우리가 어떻게든 코루틴이나 스택 전환을 얻을 것이며 이를 사용하여 await의 사용 사례를 지원할 수 있다고 믿습니다. 이는 wasm에 대한 각 호출에 대해 새로운 코루틴/스택을 생성하는 것을 의미하지만(이 제안과 달리) 적어도 일부 VM 사용자는 충분히 빠르게 만들 수 있다고 생각합니다.

VM 사람들의 관심 부족 외에도 위에서 논의한 바와 같이 @fgmccabe 및 @RossTate 에서 이 제안에 대해 몇 가지 강력한 반대를 받았습니다. 우리는 몇 가지 사항에 대해 동의하지 않지만 저는 이러한 관점과 그것들을 설명하는 데 들인 시간에 감사합니다.

결론적으로, 여기에서 앞으로 나아가려고 노력하는 것은 모든 사람의 시간을 낭비하는 것처럼 느껴집니다. 하지만 토론에 참여해주신 모든 분들께 감사드립니다! 그리고 적어도 이것이 코루틴/스택 전환의 우선 순위를 정하도록 동기를 부여하기를 바랍니다.

이 제안의 JS 부분은 기본적으로 편리한 Promise 통합을 위한 JS 설탕과 같이 미래에 관련이 있을 수 있습니다. 스택 전환 또는 코루틴을 기다리고 이것이 그 위에 작동할 수 있는지 확인해야 합니다. 그러나 나는 그것을 위해 문제를 열어둘 가치가 없다고 생각하므로 닫습니다.