Jorge Aparicio 25b9b06d1c CAS Pool x86_64: lazily initialized ANCHOR
this reduces the chances of hitting the 32-bit address space issue on x86_64

instead of (always) using a static ANCHOR variable located in .bss we lazily initialize the ANCHOR
variable using the value passed to the first `Ptr::new` invocation. In practice, this means the very
first `Pool::grow` (on x86_64) call is guaranteed to work (use the given memory). Follow up `grow`
invocations are *more likely* to work (but not guaranteed) *if* all given memory comes from the
heap.

We still need an ANCHOR in .bss as a fallback because it's possible to allocate ZST on a pool
without calling `Pool::grow` (= the lazily init ANCHOR is never initialized *but* it can be read)
2021-08-26 14:17:43 +02:00
..
2021-03-25 16:51:38 +01:00
2021-05-18 11:11:30 -07:00
2021-07-28 15:23:21 +08:00
2021-04-19 21:36:38 +02:00
2021-03-25 19:42:21 +01:00
2021-03-25 17:52:15 +01:00
2021-07-28 15:23:21 +08:00
2021-03-25 17:52:15 +01:00
2021-08-04 20:40:38 +02:00
2021-03-28 09:48:34 +03:00