[lkml]   [2012]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[RFC PATCH Userspace RCU] Discourage use of pthread_atfork() for call_rcu handlers
Discourage use of glibc pthread_atfork() for call_rcu handlers due to
its inappropriate assumptions about single-threadedness while pthread
atfork handlers are executing. This results in hangs within the glibc
memory allocator.

Signed-off-by: Mathieu Desnoyers <>
diff --git a/README b/README
index 83330ea..2d29c1d 100644
--- a/README
+++ b/README
@@ -273,7 +273,20 @@ Interaction with fork()
must invoke call_rcu_before_fork() before the fork() and
call_rcu_after_fork_parent() after the fork(). The child
process must invoke call_rcu_after_fork_child().
- These three APIs are suitable for passing to pthread_atfork().
+ Even though these three APIs are suitable for passing to
+ pthread_atfork(), use of pthread_atfork() is *STRONGLY
+ DISCOURAGED* for programs calling the glibc memory allocator
+ (malloc(), calloc(), free(), ...) within call_rcu callbacks.
+ This is due to limitations in the way glibc memory allocator
+ handles calls to the memory allocator from concurrent threads
+ while the pthread_atfork() handlers are executing.
+ Combining e.g.:
+ * call to free() from callbacks executed within call_rcu worker
+ threads,
+ * executing call_rcu atfork handlers within the glibc pthread
+ atfork mechanism,
+ will sometimes trigger interesting process hangs. This usually
+ hangs on a memory allocator lock within glibc.

Thread Local Storage (TLS)

Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.

 \ /
  Last update: 2012-12-26 19:21    [W:0.080 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site