Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

s/cont.new/cont.run/g

Đang mở
  • Có gì không ổn?
#116 10 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
wasm
Lĩnh vực
compilers

Hướng nghiên cứu

Start by reading the proposal's existing cont.new, resume, and resume_throw definitions, then trace the V8 compilation and decoding flow described in the issue, including the type and function sections. The work is complete when the design decision for replacing cont.new with cont.run is agreed and the coroutine-creation and never-suspending use cases are addressed.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

It turns out that implementing cont.new is not trivial in V8. The reasons have to do with how we want to 'interpret' suspensions and subsequent resumptions.

In normal flow, a resume always follows a suspend. From the pov of a coroutine, the suspend and subsequent 'recovery' on being resumed looks a lot like calling a function:

push a1
..
push ak
push K
suspend tag
local.set r1
..
local.set rm

It is our intention to reuse the existing machinery for function calling to make this pattern as performant as possible.

cont.new does not fall into this pattern, because, instead of the return values from the suspend being on the value stack, they form the arguments to the function itself.

However, when implementing resume, we do not know whether this is the first time a coroutine is being 'woken up' or is actually following a suspend. The code generated for resume must assume the latter.

This implies that we must generate additional code for each occurrence of cont.new just to handle this mismatch. In addition, since the argument to cont.new is a funcref, not a named function, we cannot modify the code of the function itself (e.g., by adding a preamble to the compiled function).

Generating these 'co-wrappers' is a non-trivial change to the compilation flow of V8. We have to decide how to manage the wrappers that we generate and we have to decide when to generate them. Generating them at the point of compiling cont.new requires that the entire compilation chain itself can be recursively reentered and also risks generating a lot of identical looking code. Generating them during decoding (e.g. after decoding the type section and before decoding/compiling the function section) has architectural implications (polluting the compilation pipeline somewhat egregiously).

From a dynamic computation pov, having these co-wrappers is almost equivalent having cont.new automatically entering the newly created coroutine and being immediately suspended.

IMO, a cleaner design that honors reasonable implementation strategies would be to not have cont.new, but to have cont.run; which would be specified as a variant of resume and resume_throw. This would also address an issue that I have raised before: of supporting the use case where coroutines are created but which never suspend.

Ngôn ngữ chính
WebAssembly
Star
216
Fork
19
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của WebAssembly/stack-switching

Tất cả issue của WebAssembly/stack-switching

Issue tương tự

Thêm issue về Compilers

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.