On Oct 23, 2013, at 9:20 AM, Leonard Crestez <[email protected]> wrote: > You mean between the "malloc_initialized = true;" and > "malloc_mutex_unlock(&init_lock);"?
Yes. > It's not clear what this protects against. malloc_init_hard should complete > during the first malloc in the process. As long as nobody forks during the > first malloc delaying pthread_atfork should be safe, right? Consider this comment above jemalloc_constructor() in src/jemalloc.c: /* * If an application creates a thread before doing any allocation in the main * thread, then calls fork(2) in the main thread followed by memory allocation * in the child process, a race can occur that results in deadlock within the * child: the main thread may have forked while the created thread had * partially initialized the allocator. Ordinarily jemalloc prevents * fork/malloc races via the following functions it registers during * initialization using pthread_atfork(), but of course that does no good if * the allocator isn't fully initialized at fork time. The following library * constructor is a partial solution to this problem. It may still possible to * trigger the deadlock described above, but doing so would involve forking via * a library constructor that runs before jemalloc's runs. */ After your change, there are additional failure modes. For example, the main thread can create a new thread, malloc, then fork, and if the other thread makes it through malloc initialization (but not to the pthread_atfork() call) prior to the main thread's malloc and fork, then deadlock can occur. In practice jemalloc_constructor() should make it really hard to hit such races, but I remain paranoid about relaxing the initialization sequence. Thanks, Jason _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
