Hooks: Protect against reentrancy.

Previously, we made the user deal with this themselves, but that's not good
enough; if hooks may allocate, we should test the allocation pathways down
hooks.  If we're doing that, we might as well actually implement the protection
for the user.
This commit is contained in:
David Goldblatt
2018-05-15 14:15:43 -07:00
committed by David Goldblatt
parent 0379235f47
commit a7f749c9af
4 changed files with 106 additions and 12 deletions

View File

@@ -25,9 +25,9 @@
* and only calls the alloc hook).
*
* Reentrancy:
* Is not protected against. If your hooks allocate, then the hooks will be
* called again. Note that you can guard against this with a thread-local
* "in_hook" bool.
* Reentrancy is guarded against from within the hook implementation. If you
* call allocator functions from within a hook, the hooks will not be invoked
* again.
* Threading:
* The installation of a hook synchronizes with all its uses. If you can
* prove the installation of a hook happens-before a jemalloc entry point,

View File

@@ -66,6 +66,7 @@ typedef ql_elm(tsd_t) tsd_link_t;
#define MALLOC_TSD \
O(tcache_enabled, bool, bool) \
O(arenas_tdata_bypass, bool, bool) \
O(in_hook, bool, bool) \
O(reentrancy_level, int8_t, int8_t) \
O(narenas_tdata, uint32_t, uint32_t) \
O(offset_state, uint64_t, uint64_t) \
@@ -85,6 +86,7 @@ typedef ql_elm(tsd_t) tsd_link_t;
ATOMIC_INIT(tsd_state_uninitialized), \
TCACHE_ENABLED_ZERO_INITIALIZER, \
false, \
false, \
0, \
0, \
0, \