{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidazzoqauvyyxe7gp6ayybjhqk3s5sgob6b4wtuzowpeu2rb2i6jy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mliopi6vskl2"
  },
  "path": "/t/signal-semantics-for-rust/24288#post_2",
  "publishedAt": "2026-05-10T09:45:17.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "compiler_fence"
  ],
  "textContent": "Yeah, we should really document this more precisely.\n\nOn the opsem side, things behave largely like in C and C++ -- async signals (which also include HW interrupts) are considered basically \"separate threads\" with all the usual caveats (and data race UB) except that they are paired up with a \"main\" thread and have a special relationship with that thread (allowing the use of compiler_fence rather than `fence` when synchronizing with that thread).\n\nMost of the rest of this is a libs question. There, the tl;dr is that `std` APIs are generally _not_ async-signal-safe.",
  "title": "Signal semantics for Rust"
}