Rfcs: Atomic function pointers

[gnzlbg]

Following the discussion in https://github.com/rust-lang/rust/issues/51559 I am opening this to track the lack of atomic function pointers in the std library (and the ecosystem in general).

We currently have std::sync::atomic::AtomicPtr but it does not work with function pointers by design:

fn foo() {}
static Foo: AtomicPtr<fn()->()> = AtomicPtr::new(foo);

emits

error[E0308]: mismatched types
 --> src/main.rs:5:50
  |
5 | static Foo: AtomicPtr<fn()->()> = AtomicPtr::new(foo);
  |                                                  ^^^ expected *-ptr, found fn item
  |
  = note: expected type `*mut fn()`
             found type `fn() {foo}`

This is at the pure brainstorming stage, but enabling this use case is probably going to need an AtomicFnPtr or similar type unless we retrofit AtomicPtr to also work with fn items.

---

EDIT: relevant threads/rfcs:

[0] [pre-RFC: Extended atomic types](https://internals.rust-lang.org/t/pre-rfc-extended-atomic-types/3068) proposes a generic atomic type that uses constraints to be generic. I don't know if that approach can be feasible extended to function pointer types.

[1] [RFC 1543 (merged): Add more integer atomic types](https://github.com/rust-lang/rfcs/pull/1543). Only mentions AtomicPtr, but it does not mention pointers to functions.

[2] [Function pointers can be stored in atomic usizes just fine](https://github.com/rust-lang/rust/issues/51559).

[Amanieu]

The main issue that I can see here is that we would need variadic generics to make this work for all possible argument lists for the inner function type.

Also have you considered whether AtomicFnPtr should allow a "null" value? In which case it would wrap a Option<fn()> rather than a raw fn().

[hanna-kruppe]

Variadic generics aren't even enough, since fn types can have higher rank lifetimes (e.g., fn(&str) -> &str is actually a for<'a> ... binder). That issue isn't specific to atomics (e.g., it also affects trait impls for function pointers, except the magic compiler-generated ones), so there's motivation for some way to abstract over those HRLBs, but I don't know if that's even really possible and I certainly haven't heard of any proposals for how to add it to Rust.

[gnzlbg]

The main issue that I can see here is that we would need variadic generics to make this work for all possible argument lists for the inner function type.

Thinking of: fn<'a, 'b, T, U>(x: &'a T, y: &'b U) -> &'a T vs fn<'a, T, U>(x: &'a T, y: &'a U) -> &'a T vs fn<'a, T, U>(x: &'a T, y: U) -> &'a T, would variadic generic be enough?

Also have you considered whether AtomicFnPtr should allow a "null" value?

I think "null" is a perfectly valid value for a raw fn pointer, but I don't know if it is possible to have one in Rust: let x: fn()->() = std::ptr::null(); fails to compile.

[hanna-kruppe]

fn types are non-null. Unsafely type-punning a null pointer to a fn is instant UB.

[gnzlbg]

Then I think we need AtomicFnPtr<Option<fn()->()>> . . .

[Amanieu]

At this point you might as well just use my crate.

[Centril]

Ping @gnzlbg; what's the state of this?

( You can do: AtomicPtr::new(foo as *mut _) )

[kazcw]

Creating a null-valued fn pointer can't be UB, because it is safe:

fn main() {
    let foo = std::ptr::null() as *const fn() -> i32;
}

[sfackler]

@kazcw That's not a null function pointer, that's a null pointer to a function pointer.

[josephlr]

This would be very useful for defining global handlers in a safe way:

type Handler: fn(usize) -> bool;

static HANDLER: AtomicFnPtr<Handler> = AtomicFnPtr::new(None);

fn set_handler(h: Handler) {
    HANDLER.store(h, Ordering::SeqCst);
}

fn run_handler(u: usize) -> bool {
    let h: Option<Handler> = HANDLER.load(Ordering::SeqCst);
    let h = h.expect("No handler set");
    h(u)
}

This can be implemented in Rust right now by either:

• Using a Mutex w/ std
• Using AtomicUsize and transmute

It would be nice to have a safe way to do this w/ no_std.