Cache worker lowers the priority of the whole process on macOS

Aperta
  • Qualcosa non va?
#15,160 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
linux, macos, rust
Ambito
backend, performance

Direzione di ricerca

Start with crates/cache/src/worker.rs and inspect WorkerThread::lower_thread_priority and its platform-specific branches. Check the priority APIs used on Linux, Android, Apple targets, and other Unix targets, then add or run a test that verifies cache worker startup does not lower the macOS process priority. Done means the worker priority is handled per the platform behavior described in the issue, without changing the host process priority.

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

Descrizione

Problem

WorkerThread::lower_thread_priority in crates/cache/src/worker.rs calls
rustix::process::nice(3) on every target other than Windows and Fuchsia. The
intent is to lower the priority of the cache worker thread only.

On Linux, nice changes only the calling thread, so the code does what it
intends. On macOS, nice and setpriority(PRIO_PROCESS, 0, ...) change the
whole process. Apple's setpriority(2) man page states: "The setpriority()
call sets the priorities of all of the specified processes to the specified
value", where who = 0 denotes the current process. Thread-level control on
macOS uses PRIO_DARWIN_THREAD or the pthread QoS API, not PRIO_PROCESS.

As a result, each Cache (each one starts its own worker thread) adds 3 to
the nice value of the whole embedding process. All threads of the process and
every child process that it spawns after that inherit the value. An
unprivileged process cannot lower its nice value again.

The other BSDs also apply nice per process, as far as I know. I tested
only macOS.

Steps to Reproduce
[dependencies]
libc = "0.2"
wasmtime = { version = "50.0.1", default-features = false, features = ["cache", "cranelift", "runtime", "wat"] }

use wasmtime::{Cache, CacheConfig, Config, Engine, Module, Result};

fn process_nice() -> i32 {
    unsafe { libc::getpriority(libc::PRIO_PROCESS, 0) }
}

fn main() -> Result<()> {
    println!("nice before engine: {}", process_nice());
    let mut cache_config = CacheConfig::new();
    cache_config.with_directory(std::env::temp_dir().join("cache-nice-repro"));
    let mut config = Config::new();
    config.cache(Some(Cache::new(cache_config)?));
    let engine = Engine::new(&config)?;
    Module::new(&engine, "(module)")?;
    std::thread::sleep(std::time::Duration::from_millis(500));
    println!("nice after engine: {}", process_nice());
    let child = std::process::Command::new("sh").args(["-c", "ps -o nice= -p $$"]).output()?;
    print!("child process nice: {}", String::from_utf8_lossy(&child.stdout));
    Ok(())
}
Expected Results
nice before engine: 0
nice after engine: 0
child process nice:  0
Actual Results
nice before engine: 0
nice after engine: 3
child process nice:  3
Impact

Any host that enables the cache on macOS is affected, also indirectly. For
example, a host that embeds Extism with its default cache configuration and
creates five or six engines runs at nice 15 to 18. Every process that the
host starts, such as dev servers and test runners, then also runs at nice 15
to 18, and the user cannot undo it without root. With the cache turned off,
the host stays at nice 0.

Versions and Environment

Wasmtime version or commit: main at 33b89be (the same code is in v50.0.1)

Operating system: macOS 27.0.1

Architecture: aarch64

Proposed fix
  • Linux and Android: keep nice(3), which is per thread there.
  • Apple targets: call pthread_set_qos_class_self_np(QOS_CLASS_UTILITY, 0),
    which changes only the calling thread.
  • Other Unix targets: do not change the priority, and write a debug log.
    The Fuchsia branch is already a no-op in the same way.

I have a PR ready with this change and a test.

Lingua principale
Rust
Stelle
18.8k
Fork
1.9k
Merge medio
1g 3h
PR unite (30g)
382

Preparare l'ambiente

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 bytecodealliance/wasmtime

Tutte le issue di bytecodealliance/wasmtime

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.