Atomic function pointers

Following the discussion in rust-lang/rust#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 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. Only mentions AtomicPtr, but it does not mention pointers to functions.

[2] Function pointers can be stored in atomic usizes just fine.

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().

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.

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.

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

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

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

@gnzlbg

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

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

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;
}

@kazcw

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

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.

@Amanieu

@Amanieu It works for me, thanks! But I wonder why does it work while the std one does not? In other words, why std forbid "AtomicFnPtr", while your implementation can allow us to do that - what magic do you do ;) ?

Navigation Menu

Repository navigation

Atomic function pointers #2481

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Atomic function pointers #2481

Description

Activity

Amanieu commented on Jun 20, 2018

hanna-kruppe commented on Jun 20, 2018

gnzlbg commented on Jun 20, 2018

hanna-kruppe commented on Jun 20, 2018

gnzlbg commented on Jun 20, 2018

Amanieu commented on Jun 20, 2018

Centril commented on Oct 14, 2018

kazcw commented on May 10, 2019

sfackler commented on May 10, 2019

josephlr commented on Apr 17, 2020

fzyzcjy commented on Oct 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions