Edit Question - KnowledgeHub

Title Body

I'm really uncertain about the requirements POSIX places on the safety of fork in the presence of threads and signals. fork is listed as one of the async-signal-safe functions, but if there is a possibility that library code has registered pthread_atfork handlers which are not async-signal-safe, does this negate the safety of fork ? Does the answer depend on whether the thread in which the signal handler is running could be in the middle of using a resource that the atfork handlers need? Or said a different way, if the atfork handlers make use of synchronization resources (mutexes, etc.) but fork is being called from a signal handler which executed in a thread that never accesses these resources, is the program conforming? Building on this question, if "thread-safe" forking is implemented internally in the system library using the idioms suggested by pthread_atfork (obtain all locks in the prefork handler and release all locks in both the parent and child postfork handlers), then is fork ever safe to use from signal handlers in a threaded program? Isn't it possible that the thread handling the signal could be in the middle of a call to malloc or fopen / fclose and holding a global lock, resulting in deadlock during fork ? Finally, even if fork is safe in signal handlers, is it safe to fork in a signal handler and then return from the signal handler, or does a call to fork in a signal handler always necessitate a subsequent call to _exit or one of the exec family of functions before the signal handler returns?

Tags (comma-separated) Cancel