MCPcopy Create free account
hub / github.com/Snapchat/KeyDB / zone_force_unlock

Function zone_force_unlock

deps/jemalloc/src/zone.c:284–307  ·  view source on GitHub ↗

Source from the content-addressed store, hash-verified

282}
283
284static void
285zone_force_unlock(malloc_zone_t *zone) {
286 /*
287 * zone_force_lock and zone_force_unlock are the entry points to the
288 * forking machinery on OS X. The tricky thing is, the child is not
289 * allowed to unlock mutexes locked in the parent, even if owned by the
290 * forking thread (and the mutex type we use in OS X will fail an assert
291 * if we try). In the child, we can get away with reinitializing all
292 * the mutexes, which has the effect of unlocking them. In the parent,
293 * doing this would mean we wouldn't wake any waiters blocked on the
294 * mutexes we unlock. So, we record the pid of the current thread in
295 * zone_force_lock, and use that to detect if we're in the parent or
296 * child here, to decide which unlock logic we need.
297 */
298 if (isthreaded) {
299 assert(zone_force_lock_pid != -1);
300 if (getpid() == zone_force_lock_pid) {
301 jemalloc_postfork_parent();
302 } else {
303 jemalloc_postfork_child();
304 }
305 zone_force_lock_pid = -1;
306 }
307}
308
309static void
310zone_statistics(malloc_zone_t *zone, malloc_statistics_t *stats) {

Callers 1

zone_reinit_lockFunction · 0.70

Calls 2

jemalloc_postfork_parentFunction · 0.70
jemalloc_postfork_childFunction · 0.70

Tested by

no test coverage detected