Cache worker lowers the priority of the whole process on macOS

Abierto
  • ¿Algo no está bien?
#15,160 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
linux, macos, rust
Área
backend, performance

Línea de trabajo

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.

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

Descripción

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.

Lenguaje dominante
Rust
Estrellas
18.8k
Forks
1.9k
Merge medio
1 d 3 h
PR fusionados (30 d)
380

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

Todos los issues de bytecodealliance/wasmtime

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.