Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

s/cont.new/cont.run/g

Abierto
  • ¿Algo no está bien?
#116 10 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
wasm
Área
compilers

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
WebAssembly
Estrellas
216
Forks
19
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WebAssembly/stack-switching

Todos los issues de WebAssembly/stack-switching

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.