CooperativeExecutor.runUntil sleeps until the next timer while runnable jobs are queued

Aperta Adatta ai principianti
#92,461 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
swift

Direzione di ricerca

Inizia in stdlib/public/Concurrency/CooperativeExecutor.swift intorno a CooperativeExecutor.runUntil(_:) alle righe 286-331, quindi esegui la riproduzione WASI fornita sul runtime interessato. La correzione è completa quando i job eseguibili vengono eseguiti prima che l’executor attenda un timer ed entrambi gli scenari terminano entro millisecondi con il watchdog annullato; aggiungi un test di regressione se la struttura dei test circostante lo supporta.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

triage needed
Description

On wasm32-unknown-wasip1, a task that becomes runnable while another task is inside Task.sleep does not run until that sleep's deadline. This applies to a task that called Task.yield() and to a task whose awaited child has finished.

CooperativeExecutor.runUntil(_:) takes the ready jobs with runQueue.take(), runs them, and then sleeps for the time to the next timer. Jobs enqueued while those ran are in runQueue at that point; runQueue.isEmpty is checked only when no timer is pending.

https://github.com/swiftlang/swift/blob/swift-6.4.0-RELEASE/stdlib/public/Concurrency/CooperativeExecutor.swift#L286-L331

Reproduction
// Package.swift: swift-tools-version 6.3, one executableTarget named repro.
// Sources/repro/main.swift
let sleepSeconds: UInt64 = 5
let clock = ContinuousClock()
let start = clock.now
func stamp(_ what: String) { print("[\(clock.now - start)] \(what)") }

func scenario(_ name: String, yields: Int) async {
    stamp("\(name): start")
    let watchdog = Task {
        try? await Task.sleep(nanoseconds: sleepSeconds * 1_000_000_000)
        stamp("\(name): watchdog woke, cancelled=\(Task.isCancelled)")
    }
    let worker = Task {
        for _ in 0 ..< yields { await Task.yield() }
        stamp("\(name): worker done")
    }
    await worker.value
    watchdog.cancel()
    stamp("\(name): end")
}

await scenario("no-yield", yields: 0)
await scenario("yield", yields: 50)
stamp("all done")
$ swift sdk install https://download.swift.org/swift-6.4.0-release/wasm-sdk/swift-6.4.0-RELEASE/swift-6.4.0-RELEASE_wasm.artifactbundle.tar.gz --checksum f07b7be3c586d92d7a07051fc6d303b87ebea67eadc40640ba59d5a8b79aa86d
$ swift build -c release --swift-sdk swift-6.4.0-RELEASE_wasm
$ wasmkit run .build/out/Products/Release-webassembly-wasm32/repro.wasm
[0.003 seconds] no-yield: start
[0.006 seconds] no-yield: worker done
[5.023 seconds] no-yield: end
[5.024 seconds] yield: start
[5.026 seconds] no-yield: watchdog woke, cancelled=true
[10.036 seconds] yield: watchdog woke, cancelled=false
[10.039 seconds] yield: worker done
[10.039 seconds] yield: end

With no yields the worker is done at 6 ms, yet the task awaiting it resumes at 5 s. With yields the worker does not advance at all until the watchdog's sleep has run its full length, by which time nobody has cancelled it.

Expected behavior

Jobs that became runnable during a pass run before the executor sleeps; it should sleep only when the run queue is empty. Each scenario above should end within milliseconds, with the watchdog cancelled before it wakes.

A possible fix is to guard the sleep: if let toWait, runQueue.isEmpty { _sleep(…) } (or continue when runQueue is not empty). Untested.

Environment

Swift version 6.4 (swift-6.4-RELEASE), Ubuntu 24.04 aarch64 host, Swift SDK swift-6.4.0-RELEASE_wasm (wasm32-unknown-wasip1), run with the WasmKit 0.3.1 the toolchain ships.

Also reproduced with a binary built by Swift 6.3.3 and its Wasm SDK. The same code is present in release/6.3, release/6.4.x, release/6.4.1, swift-6.4.0-RELEASE, and main (as of 2026-09-19).

Additional information

The Swift version makes no difference; whether the WASI runtime's poll_oneoff actually sleeps does. Time for a four-scenario variant of the program (5 s sleep each) to finish, same two binaries on three runtimes:

Binary WasmKit 0.1.6 (ships with 6.3.3) WasmKit 0.3.1 (ships with 6.4.0) wasmtime 30.0.2
built with Swift 6.3.3 + its Wasm SDK 0.01 s 20 s 20 s
built with Swift 6.4.0 + its Wasm SDK 0.01 s 20 s 20 s

Impact: any program on these targets that keeps a timer pending while other tasks make progress — a timeout or watchdog around a body is the common case — runs at the pace of its timers. It surfaced as a test suite whose every deadline-bounded test took exactly its deadline (300 s) under the 6.4.0 toolchain while passing in seconds under 6.3.3: https://github.com/sinoru/swift-synchronization-kit/issues/4

#90096 (enabling Task.sleep in Embedded Swift) removes the #if !$Embedded guards around the same timer queues, so the same stall would presumably appear there once it lands.

Lingua principale
Swift
Stelle
70.4k
Fork
10.8k
Merge medio
2g 2h
PR unite (30g)
461

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di swiftlang/swift

Tutte le issue di swiftlang/swift

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.