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.
mcfork(estranged = FALSE)mcexit(exit.code = 0L, send = NULL)
logical, if TRUE then the new process has
no ties to the parent process, will not show in the list of
children and will not be killed on exit.
process exit code. By convention 0L signifies
a clean exit, 1L an error.
if not NULL send this data before exiting
(equivalent to using sendMaster).
mcfork returns an object of the class "childProcess" to
the master and of class "masterProcess" to the child: both the
classes inherit from class "process". If estranged is
set to 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
with components 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., mcparallel,
mclapply and 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
connections.
This is a very low-level API for expert use only.
The mcfork function provides an interface to the fork
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
sendChildStdin).
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 send
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
parallel:::rmChild.