These are low-level functions, not available on Windows, and not exported from the namespace.
mcfork creates a new child process as a copy of the current R process.
mcexit closes the current child process, informing the master
process as necessary.
1 2 3
process exit code. By convention
mcfork function provides an interface to the
system call. In addition it sets up a pipe between the master and
child process that can be used to send data from the child process
to the master (see
sendMaster) and child's ‘stdin’ is
re-mapped to another pipe held by the master process (see
If you are not familiar with the
fork system call, do not use
this function directly as it leads to very complex inter-process
interactions amongst the R processes involved.
In a nutshell
fork spawns a copy (child) of the current
process, that can work in parallel to the master (parent)
process. At the point of forking both processes share exactly the
same state including the workspace, global options, loaded packages
etc. Forking is relatively cheap in modern operating systems and no
real copy of the used memory is created, instead both processes
share the same memory and only modified parts are copied. This makes
mcfork an ideal tool for parallel processing since there is no
need to setup the parallel working environment, data and code is
shared automatically from the start.
mcexit is to be run in the child process. It sends
to the master (unless
NULL) and then shuts down the child
process. The child can also be shut down by sending it the signal
SIGUSR1, as is done by the unexported function
mcfork returns an object of the class
the master and of class
"masterProcess" to the child: both the
classes inherit from class
TRUE then the child process will be of the class
"estrangedProcess" and cannot communicate with the master
process nor will it show up on the list of children. These are lists
pid (the process id of the other
process) and a vector
fd of the two file descriptor numbers
for ends in the current process of the inter-process pipes.
mcexit never returns.
It is strongly discouraged to use
mcfork and the
higher-level functions which rely on it (e.g.,
pvec) in GUI or embedded environments,
because it leads to several processes sharing the same GUI which will
likely cause chaos (and possibly crashes). Child processes should
never use on-screen graphics devices. Some precautions have been
taken to make this usable in
R.app on macOS, but users of
third-party front-ends should consult their documentation.
This can also apply to other connections (e.g., to an X server) created before forking, and to files opened by e.g. graphics devices.
Note that tcltk counts as a GUI for these purposes since
Tcl runs an event loop. That event loop is inhibited in a
child process but there could still be problems with Tk graphical
This is a very low-level API for expert use only.
Simon Urbanek and R Core.
Derived from the multicore package formerly on CRAN.
1 2 3 4 5 6 7 8