{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3w222pdzfdppqk3tlk33yrleqq6bqdsyq5pv3tqi46nydpgxgea",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mndkhuuslgb2"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289?page=3#post_50",
  "publishedAt": "2026-06-02T18:47:58.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "It's worth noting that (in a previous program that I'm no longer working on) I ended up with a use case for after-the-fact-verfieid racy reads, seqlock style, for which the atomic-bytewise approach wouldn't work: I was writing an async-signal-safe memory allocator (i.e. it can allocate from a signal handler, even if the signal interrupted a use of the allocator), which stored its freelist in the free allocations themselves. Allocating would work like this:\n\n  1. Read the pointer to the head of the freelist;\n  2. Read the memory it points to in order to discover the next entry of the freelist – the pointer found there will be the new head of the freelist if step 3 succeeds;\n  3. Atomically swap the head of the freelist with the pointer that was read in step 2, only if the head of the freelist has not changed since step 1 (not even changed and changed back, to avoid the ABA problem).\n\n\n\nBecause the allocator is async-signal-safe, it is possible that, between step 1 and 2, a signal handler (or another thread) will allocate the first block of memory on the freelist. In this situation, step 2 will read from memory that has already been allocated and is already in use by the signal handler or other thread. The result will then be discarded in step 3 (due to the head of the freelist having changed) and will not be used for anything, but it was still actually read at the hardware level. Additionally, you can't rely on the writing code to use only atomic writes to the memory, because in this case the memory has been returned as an apparently normal allocation.\n\nI no longer actually need to use this style of memory allocator for anything (I changed other parts of my design so that the ability to do this sort of thing wasn't necessary), but maybe someone else does. As such, I would if possible prefer a model which makes this sort of code legal, not just seqlocks.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}