Cache worker lowers the priority of the whole process on macOS

オープン
  • 何か問題がありますか？
#15,160 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
linux, macos, rust
領域
backend, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
18.8k
フォーク
1.9k
平均マージ
1日 3時間
マージ済み PR（30日）
380

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

bytecodealliance/wasmtime のほかの issue

bytecodealliance/wasmtime の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。