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

Wait until deadline variant

Abierto
#231 0 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
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
wasm

Línea de trabajo

El issue no nombra archivos ni pruebas. Empieza leyendo la dependencia #230 y después revisa la discusión de la propuesta sobre Atomics.waitAsync y las esperas absolutas frente a las relativas en distintos sistemas operativos y hardware embebido. El resultado debería ser una variante de espera basada en un plazo, especificada con una semántica clara y con su relación con la forma existente basada en una duración.

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

Descripción

This obviously depends on #230.

Waiting for a duration is useful for simple blocking waits, but event loops generally find deadlines more convenient to work with, since you can just throw all the deadlines into a heap, sort by deadline, and (if your loop is multi-threaded) make your wait condition include timer add/remove events. Browser runtimes would already likely need a similar model anyways because of Atomics.waitAsync, but it's easy for a runtime using one model to expose the other.

Also, the type of wait differs heavily between platforms, with some accepting absolute deadlines, some accepting relative timeouts, and some accepting both:

  • Operating systems:
    • Linux: all futex waits other than FUTEX_WAIT use absolute deadlines, and even that one has an absolute alternative documented in its manpages.
    • Fuschia only uses absolute deadlines in its zx_futex_wait syscall, and offers no relative equivalent.
    • macOS provides both os_sync_wait_on_address_with_deadline and os_sync_wait_on_address_with_timeout.
    • OpenBSD and Windows only offer relative timeouts in their APIs.
    • pthread_condvar_timedwait only uses absolute timeouts.
  • Embedded hardware:
    • 32-bit ARM's SysTick is effectively timeout-based. It decrements every tick until it hits zero, in which it then triggers an interrupt. Setting the register essentially sets the number of ticks to wait before sending the interrupt.
    • RISC-V's privileged spec uses *timecmp registers corresponding to *time targets and triggers an interrupt whenever they're equal, effectively using a deadline-based system.
    • x86-64's HPET works nearly identically to RISC-V's mechanism. (This mostly only has relevance for VM-based server-side runtimes.)
    • The real-time clock specified by ACPI for motherboards uses deadlines. (This is sometimes used on high-end microcontrollers.)

Will note that it's easy to do one in terms of the other.

  • If all waits are absolute, relative waits are as simple as using a deadline of current_time() + timeout.
  • If all waits are relative, absolute waits are as simple as using a timeout of max(target_time - current_time(), 0).
Lenguaje dominante
WebAssembly
Estrellas
769
Forks
54
Métricas de merge de PR
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/threads

Todos los issues de WebAssembly/threads

Issues similares

Más issues de Operating Systems

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.