@@ -115,6 +115,31 @@ use crate::{cmp, ptr};
115115/// Whether allocations happen or not is not part of the program behavior, even if it
116116/// could be detected via an allocator that tracks allocations by printing or otherwise
117117/// having side effects.
118+ ///
119+ /// # Re-entrance
120+ ///
121+ /// When implementing a global allocator one has to be careful not to create an infinitely recursive
122+ /// implementation by accident, as many constructs in the Rust standard library may allocate in
123+ /// their implementation. For example, on some platforms [`std::sync::Mutex`] may allocate, so using
124+ /// it is highly problematic in a global allocator.
125+ ///
126+ /// Generally speaking for this reason one should stick to library features available through
127+ /// [`core`], and avoid using [`std`] in a global allocator. A few features from [`std`] are
128+ /// guaranteed to not use the global allocator:
129+ ///
130+ /// - [`std::thread_local`],
131+ /// - [`std::thread::current`],
132+ /// - [`std::thread::park`] and [`std::thread::Thread`]'s [`unpark`] method and
133+ /// [`Clone`] implementation.
134+ ///
135+ /// [`std`]: ../../std/index.html
136+ /// [`std::sync::Mutex`]: ../../std/sync/struct.Mutex.html
137+ /// [`std::thread_local`]: ../../std/macro.thread_local.html
138+ /// [`std::thread::current`]: ../../std/thread/fn.current.html
139+ /// [`std::thread::park`]: ../../std/thread/fn.park.html
140+ /// [`std::thread::Thread`]: ../../std/thread/struct.Thread.html
141+ /// [`unpark`]: ../../std/thread/struct.Thread.html#method.unpark
142+
118143#[ stable( feature = "global_alloc" , since = "1.28.0" ) ]
119144pub unsafe trait GlobalAlloc {
120145 /// Allocates memory as described by the given `layout`.
0 commit comments