Skip to content

Tracking issue for static synchronization primitives #27717

Closed
@alexcrichton

Description

@alexcrichton

This is a tracking issue for the unstable static_mutex, static_condvar, and static_rwlock features in the standard library. Each of these represents a separate StaticFoo type (next to the type Foo) to provide a synchronization primitive that can be constructed in a static context. This unfortunately has a few drawbacks:

  • StaticMutex does not have a type parameter for the data that it protects (unlike Mutex<T>)
  • Having two types for almost the same purpose is quite unfortunate.

Ideally all of these types would be removed in favor of being able to construct a Mutex<T> statically. This can almost be done with const fn, but the implementation of each of these primitives currently has an internal Box which can't be constructed in a static context. A solution should probably be devised along the lines of:

  • A "stable address" primitive could be created which is a Box at runtime and just a plain address when inlined into a static. It also wouldn't have a destructor for the purposes of checking whether statics have destructors.
  • The box operator could be allowed in a const fn context perhaps. Instead of allocating memory on the heap it could instead "allocate" memory in the data section of an executable at compile time. The destructor would end up being ignored and never run somehow, possibly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions