Special Issues for fork() and Solaris Threads

Prior to the Solaris 10 release, Solaris threads and POSIX threads defined the behavior of fork() differently. See Process Creation: exec and exit Issues for a thorough discussion of fork() issues.

Solaris libthread supported both fork() and fork1(). The fork() call has “fork-all” semantics. fork() duplicated everything in the process, including threads and LWPs, creating a true clone of the parent. The fork1() call created a clone that had only one thread. The process state and address space are duplicated, but only the calling thread was cloned.

POSIX libpthread supported only fork(), which has the same semantics as fork1() in Solaris threads.

Whether fork() has “fork-all” semantics or “fork-one” semantics was dependent on which library is used. Link with -lthread to assign “fork-all” semantics to fork(). Link with -lpthread to assign “fork-one” semantics to fork().

Effective with the Solaris 10 release, fork() has the same semantics in both Solaris threads and POSIX threads. More specifically, fork1() semantics replicate only the caller. A new function, forkall() , is provided for those applications that require replicate-all semantics.

See Compiling and Linking a Multithreaded Program for more details.