This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Multithread fork and atfork handlers


While working on BZ#18023 by checking current glibc alloca and related
functions, I noted fork implementation (sysdeps/nptl/fork.c) used to
replicate the atfork handlers list backward to invoke the child handler
after fork/clone syscall.

The internal atfork handlers is implemented as a single-linked list
so a lock-free algorithm can be used, trading fork mulithread call
performance for some code complexity and dynamic stack allocation
(since the backwards list should not fail).

It could be implemented much more simpler and without any extra dynamic
stack allocation if handler were a double-linked list. The downside would
a serialization of fork call in multithread, since the double-linked list
would not be possible in a lock-free scenario (there is some algorithms 
which seems to implement it, but I am not sure how portable they are).

The question is whether we still care for fork in mulithread performance
and if the possible stack overflow in its call call pays off.  I am not
sure since fork in multithread is tricky, default and recommended usage is 
to precede a execve call and posix_spawn should be as faster if not faster.

 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]