summaryrefslogtreecommitdiffstats
path: root/client.mk
diff options
context:
space:
mode:
authorOlivier Certner <olce.palemoon@certner.fr>2021-01-06 11:25:27 +0100
committerOlivier Certner <olce.palemoon@certner.fr>2021-01-07 17:34:03 +0100
commitf76695c1ce032b634f3e0e2a593aebdd1d49703b (patch)
tree62653f3a74e8c046d154c30e04ae978335ba9b60 /client.mk
parentda217348d9e7fe1e22df725c3b48a149e7dd9f54 (diff)
downloadUXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar
UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.gz
UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.lz
UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.xz
UXP-f76695c1ce032b634f3e0e2a593aebdd1d49703b.zip
Issue #1699 - Part 3a: mozjemalloc: Memory barriers on 'malloc_initialized'
The barriers are here to make sure that setting 'malloc_initialized' at end of init must be noticed later by any thread running on a different core. They are in theory necessary in the absence of an explicit pthread lock. What could happen is that the thread doing the initialization later spawns other threads that could not have the updated 'malloc_initialized' value, leading to a second initialization. This is dependent on whether OSes force a full memory barrier before the new thread is run, which I don't know, and don't want to bother. This was done for FreeBSD only, for the sake of robustness. In theory, this would be needed on Windows too.
Diffstat (limited to 'client.mk')
0 files changed, 0 insertions, 0 deletions