|
10 | 10 | //!
|
11 | 11 | //! is called "pinning." We would say that a value which satisfies these guarantees has been
|
12 | 12 | //! "pinned," in that it has been permanently (until the end of its lifespan) attached to its
|
13 |
| -//! location in memory, as though pinned to a pinboard. Pinning a value is incredibly useful in |
14 |
| -//! that it provides the necessary guarantees[^guarantees] for [`unsafe`] code to be able to |
15 |
| -//! dereference raw pointers to the pinned value for the duration it is pinned (which, |
16 |
| -//! [as we'll see later][drop-guarantee], is necessarily from the time the value is first pinned |
17 |
| -//! until the end of its lifespan). This concept of "pinning" is necessary to implement safe |
18 |
| -//! interfaces on top of things like self-referential types and intrusive data structures which |
19 |
| -//! cannot currently be modeled in fully safe Rust using only borrow-checked |
20 |
| -//! [references][reference]. |
| 13 | +//! location in memory, as though pinned to a pinboard. Pinning a value is an incredibly useful |
| 14 | +//! building block for [unsafe] code to be able to reason about whether a raw pointer to the |
| 15 | +//! pinned value is still valid. [As we'll see later][drop-guarantee], this is necessarily from the |
| 16 | +//! time the value is first pinned until the end of its lifespan. This concept of "pinning" is |
| 17 | +//! necessary to implement safe interfaces on top of things like self-referential types and |
| 18 | +//! intrusive data structures which cannot currently be modeled in fully safe Rust using only |
| 19 | +//! borrow-checked [references][reference]. |
21 | 20 | //!
|
22 | 21 | //! "Pinning" allows us to put a *value* which exists at some location in memory into a state where
|
23 | 22 | //! safe code cannot *move* that value to a different location in memory or otherwise invalidate it
|
|
28 | 27 | //! and not the compiler. In this way, we can allow other [`unsafe`] code to rely on any pointers
|
29 | 28 | //! that point to the pinned value to be valid to dereference while it is pinned.
|
30 | 29 | //!
|
31 |
| -//! [^guarantees]: Pinning on its own does not provide *all* the invariants necessary here. However, |
32 |
| -//! in order to validly pin a value in the first place, it must already satisfy the other invariants |
33 |
| -//! for it to be valid to dereference a pointer to that value while it is pinned, and using the |
34 |
| -//! [`Drop` guarantee][self#subtle-details-and-the-drop-guarantee], we can ensure that any |
35 |
| -//! interested parties are notified before the value becomes no longer pinned, i.e. when the value |
36 |
| -//! goes out of scope and is invalidated. |
37 |
| -//! |
38 | 30 | //! Note that as long as you don't use [`unsafe`], it's impossible to create or misuse a pinned
|
39 | 31 | //! value in a way that is unsound. See the documentation of [`Pin<Ptr>`] for more
|
40 | 32 | //! information on the practicalities of how to pin a value and how to use that pinned value from a
|
|
0 commit comments