{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiczyhq7shbe3ezaczudyduys7dotbt3lqttutfpblre5tntk5bo54",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlgzx6ebvs42"
  },
  "path": "/t/signal-semantics-for-rust/24288#post_1",
  "publishedAt": "2026-05-09T19:54:59.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Hello everyone!\n\nSome operating systems have a concept of asynchronous signals -- an external events that can interrupt the control flow of a thread and cause it to execute a special function, called a _signal handler_. A control flow can be redirected into a signal handler from any point at which the signal is not blocked, which makes installing signal handlers very unsafe and requires caution while implementing a signal handler. C and C++ standards, as well as POSIX, specify what a signal is and what semantics they have, and what a signal handler can safely do.\n\nI propose providing documentation what can a signal handler do in a Rust program, specifically:\n\n  * What functions from the standard library (`core` and maybe `std`) can be called from a signal handler?\n  * Allowed interactions with global objects. As far as I understand, a signal handler can only safely interact with immutable (without interior mutability) and atomic (`core::sync::atomic`) objects\n  * Safety of using the Rust formatting subsystem (`core::fmt`) -- can it be safe, what types from the standard library can be safely formatted\n\n",
  "title": "Signal semantics for Rust"
}