(0011814)
cndougla
09-23-08 09:05
|
According to the POSIX standard for fork (man 3p fork):
"If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called."
Here's a listing of all the POSIX stipulated async-signal-safe functions: http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/MTP/p40.html. [^]
I have audited the uClibc source code to try to find all the mutexes used by these functions so that a proper fork call will not hang as long as the child process only uses these async-signal-safe functions. My audit (hopefully accurate) showed that the only mutexes used were malloc mutexes and two fork mutexes (pthread_atfork mutex and pthread_once_mutex).
The attached patch locks all of these mutexes before calling the real fork syscall. The parent thread unlocks the mutexes afterwards while the child process reinitializes them. All three malloc libraries are supported and compile cleanly, however, only malloc-standard was tested. A modification to the "malloc" (i.e. not malloc-standard nor malloc-simple) library was made to remove the two heap locks from the heap structure so they could be made available through an extern variable. Also, a new __libc_lock_init_adaptive macro was added to the libc-lock.h header as well as a modification of the __libc_lock_init_recursive macro as its form did not match up with the current recursive lock type. |
htargs.c [^] (5,955 bytes) 09-15-08 14:24
