summaryrefslogtreecommitdiff
path: root/mailnews/jsaccount/modules
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 /mailnews/jsaccount/modules
parentda217348d9e7fe1e22df725c3b48a149e7dd9f54 (diff)
downloaduxp-f76695c1ce032b634f3e0e2a593aebdd1d49703b.tar.gz
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 'mailnews/jsaccount/modules')
0 files changed, 0 insertions, 0 deletions