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

Offen Anfängerfreundlich
#92,461 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
swift

Rechercherichtung

Beginne in stdlib/public/Concurrency/CooperativeExecutor.swift im Bereich von CooperativeExecutor.runUntil(_:) in den Zeilen 286-331 und führe dann die bereitgestellte WASI-Reproduktion auf der betroffenen Runtime aus. Die Korrektur ist vollständig, wenn ausführungsbereite Jobs ausgeführt werden, bevor der Executor auf einen Timer wartet, und beide Szenarien innerhalb von Millisekunden mit abgebrochenem Watchdog abgeschlossen werden; füge einen Regressionstest hinzu, wenn die umgebende Teststruktur dies unterstützt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Swift
Sterne
70.4k
Forks
10.8k
Ø Merge
2 T. 2 Std.
Gemergte PRs (30 T.)
461

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus swiftlang/swift

Alle Issues in swiftlang/swift

Ähnliche Issues

Weitere Issues zu Swift

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.