[PATCH 1/2] Delay pthread_atfork registering.

Leonard Crestez lcrestez at ixiacom.com
Wed Oct 23 09:20:42 PDT 2013


You mean between the "malloc_initialized = true;" and "malloc_mutex_unlock(&init_lock);"?

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?

From: Jason Evans [jasone at canonware.com]
Sent: Tuesday, October 22, 2013 23:33
To: Leonard Crestez
Cc: jemalloc-discuss at canonware.com
Subject: Re: [PATCH 1/2] Delay pthread_atfork registering.

On Oct 21, 2013, at 2:11 PM, Leonard Crestez <lcrestez at ixiacom.com> wrote:
> This function causes recursive allocation on LinuxThreads.
> Signed-off-by: Crestez Dan Leonard <lcrestez at ixiacom.com>
> ---
>  src/jemalloc.c | 23 ++++++++++++-----------
>  1 file changed, 12 insertions(+), 11 deletions(-)

We should probably keep the pthread_atfork() call prior to releasing init_lock (just need to move it up a couple of lines).  Although jemalloc cannot completely prevent races between allocator initialization and fork(2), it can at least prevent races if all threads allocate prior to the fork().


More information about the jemalloc-discuss mailing list