Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
fork(2)				 System	Calls			       fork(2)

NAME
       fork, fork1, forkall - create a new process

SYNOPSIS
       #include	<sys/types.h>
       #include	<unistd.h>

       pid_t fork(void);

       pid_t fork1(void);

       pid_t forkall(void);

DESCRIPTION
       The  fork(), fork1(), and forkall() functions create a new process. The
       address space of	the new	process	(child process)	is an  exact  copy  of
       the  address  space  of the calling process (parent process). The child
       process inherits	the following attributes from the parent process:

	 o  real user ID, real group ID, effective user	ID, effective group ID

	 o  environment

	 o  open file descriptors

	 o  close-on-exec flags	(see exec(2))

	 o  signal  handling  settings	(that  is, SIG_DFL, SIG_IGN, SIG_HOLD,
	    function address)

	 o  supplementary group	IDs

	 o  set-user-ID	mode bit

	 o  set-group-ID mode bit

	 o  profiling on/off status

	 o  nice value (see  nice(2))

	 o  scheduler class (see priocntl(2))

	 o  all	attached shared	memory segments	(see shmop(2))

	 o  process group ID --	memory mappings	(see mmap(2))

	 o  session ID (see exit(2))

	 o  current working directory

	 o  root directory

	 o  file mode creation mask (see umask(2))

	 o  resource limits (see  getrlimit(2))

	 o  controlling	terminal

	 o  saved user ID and group ID

	 o  task ID and	project	ID

	 o  processor bindings (see processor_bind(2))

	 o  processor set bindings (see	pset_bind(2))

	 o  process privilege sets (see	getppriv(2))

	 o  process flags (see getpflags(2))

	 o  active contract templates (see contract(4))

       Scheduling priority and any per-process scheduling parameters that  are
       specific	 to  a	given scheduling class might or	might not be inherited
       according to the	policy of that particular class	(see priocntl(2)). The
       child process might or might not	be in the same process contract	as the
       parent (see process(4)).	The child  process  differs  from  the	parent
       process in the following	ways:

	 o  The	child process has a unique process ID which does not match any
	    active process group ID.

	 o  The	child process has a different parent process ID	(that is,  the
	    process ID of the parent process).

	 o  The	 child	process	has its	own copy of the	parent's file descrip-
	    tors and directory streams.	Each of	the child's  file  descriptors
	    shares  a common file pointer with the corresponding file descrip-
	    tor	of the parent.

	 o  Each shared	memory segment	remains	 attached  and	the  value  of
	    shm_nattach	is incremented by 1.

	 o  All	semadj values are cleared (see semop(2)).

	 o  Process  locks, text locks,	data locks, and	other memory locks are
	    not	inherited by the child (see plock(3C) and memcntl(2)).

	 o  The	child process's	tms structure is  cleared:  tms_utime,	stime,
	    cutime, and	cstime are set to 0 (see times(2)).

	 o  The	 child processes resource utilizations are set to 0; see getr-
	    limit(2). The it_value and it_interval values for the  ITIMER_REAL
	    timer are reset to 0; see getitimer(2).

	 o  The	set of signals pending for the child process is	initialized to
	    the	empty set.

	 o  Timers created by timer_create(3RT)	are not	inherited by the child
	    process.

	 o  No asynchronous input or asynchronous output operations are	inher-
	    ited by the	child.

	 o  Any	preferred hardware address tranlsation sizes (see  memcntl(2))
	    are	inherited by the child.

	 o  The	child process holds no contracts (see contract(4)).

       Record  locks  set by the parent	process	are not	inherited by the child
       process (see fcntl(2)).

       Although	any open door descriptors in the  parent  are  shared  by  the
       child, only the parent will receive a door invocation from clients even
       if the door descriptor is open in the child. If a descriptor is	closed
       in  the	parent,	 attempts  to operate on the door descriptor will fail
       even if it is still open	in the child.

   Threads
       A call to forkall() replicates in the child process all of the  threads
       (see  thr_create(3C)  and  pthread_create(3C)) in the parent process. A
       call to fork1()	replicates  only  the  calling	thread	in  the	 child
       process.

       In Solaris 10, a	call to	fork() is identical to a call to fork1(); only
       the calling thread is replicated	in the	child  process.	 This  is  the
       POSIX-specified behavior	for fork().

       In  previous  releases  of  Solaris, the	behavior of fork() depended on
       whether or not the  application	was  linked  with  the	POSIX  threads
       library.	 When  linked  with  -lthread (Solaris Threads)	but not	linked
       with -lpthread (POSIX Threads), fork() was the same as forkall().  When
       linked with -lpthread, whether or not also linked with -lthread,	fork()
       was the same as fork1().

       In Solaris 10, neither -lthread nor -lpthread is	 required  for	multi-
       threaded	 applications.	The  standard C	library	provides all threading
       support for both	sets of	application programming	interfaces.   Applica-
       tions that require replicate-all	fork semantics must call forkall().

   fork() Safety
       If  a  multithreaded application	calls fork() or	fork1(), and the child
       does more than simply call one of the exec(2)  functions,  there	 is  a
       possibility  of deadlock	occurring in the child.	The application	should
       use pthread_atfork(3C) to ensure	safety with respect to this  deadlock.
       Should  there  be  any  outstanding mutexes throughout the process, the
       application should call pthread_atfork()	to wait	for and	acquire	 those
       mutexes	 prior	to  calling  fork()  or	 fork1().  See	 "MT-Level  of
       Libraries" on the attributes(5) manual page.

RETURN VALUES
       Upon successful completion, fork(), fork1(), and	forkall() return 0  to
       the child process and return the	process	ID of the child	process	to the
       parent process. Otherwise, (pid_t)-1 is returned	to the parent process,
       no child	process	is created, and	errno is set to	indicate the error.

ERRORS
       The fork(), fork1(), and	forkall()function will fail if:

       EAGAIN	       A  resource  control  or	  limit	on the total number of
		       processes, tasks	or LWPs	under execution	 by  a	single
		       user,  task, project, or	zone has been exceeded,	or the
		       total amount of system memory available is  temporarily
		       insufficient to duplicate this process.

       ENOMEM	       There is	not enough swap	space.

       EPERM	       The  {PRIV_PROC_FORK}  privilege	is not asserted	in the
		       effective set of	the calling process.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |fork() is	Standard. fork1()  |
       |			     |and forkall() are	Stable.	   |
       +-----------------------------+-----------------------------+
       |MT-Level		     |Async-Signal-Safe.	   |
       +-----------------------------+-----------------------------+

SEE ALSO
       alarm(2), exec(2), exit(2), fcntl(2), getitimer(2), getrlimit(2),  mem-
       cntl(2),	mmap(2), nice(2), priocntl(2), semop(2),  shmop(2),  times(2),
       umask(2),  door_create(3DOOR), exit(3C),	plock(3C), pthread_atfork(3C),
       pthread_create(3C), signal(3C), system(3C),  thr_create(3C)  timer_cre-
       ate(3RT),   wait(3C),   contract(4),   process(4)attributes(5),	privi-
       leges(5), standards(5)

NOTES
       An applications should call _exit() rather than exit(3C)	if  it	cannot
       execve(),  since	 exit()	will flush and close standard I/O channels and
       thereby corrupt the parent  process's  standard	I/O  data  structures.
       Using exit(3C) will flush buffered data twice. See exit(2).

       The thread in the child that calls fork() or fork1() must not depend on
       any resources held by threads that no longer exist  in  the  child.  In
       particular, locks held by these threads will not	be released.

       In  a multithreaded process, forkall() in one thread can	cause blocking
       system calls to be interrupted and return with an EINTR error.

SunOS 5.10			  19 Jul 2004			       fork(2)

NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | ERRORS | ATTRIBUTES | SEE ALSO | NOTES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=fork&sektion=2&manpath=SunOS+5.10>

home | help