1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104
|
% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/batchtools_local.R
\name{batchtools_local}
\alias{batchtools_local}
\alias{batchtools_interactive}
\title{batchtools local and interactive futures}
\usage{
batchtools_local(
expr,
envir = parent.frame(),
substitute = TRUE,
globals = TRUE,
label = NULL,
workers = 1L,
registry = list(),
...
)
}
\arguments{
\item{expr}{The R expression to be evaluated}
\item{envir}{The environment in which global environment
should be located.}
\item{substitute}{Controls whether \code{expr} should be
\code{substitute()}:d or not.}
\item{globals}{(optional) a logical, a character vector, a named list, or a
\link[globals:Globals]{Globals} object. If TRUE, globals are identified by code
inspection based on \code{expr} and \code{tweak} searching from environment
\code{envir}. If FALSE, no globals are used. If a character vector, then
globals are identified by lookup based their names \code{globals} searching
from environment \code{envir}. If a named list or a Globals object, the
globals are used as is.}
\item{label}{(optional) Label of the future (where applicable, becomes the
job name for most job schedulers).}
\item{workers}{(optional) The maximum number of workers the batchtools
backend may use at any time. Interactive and "local" backends can only
process one future at the time (\code{workers = 1L}), whereas HPC backends,
where futures are resolved via separate jobs on a scheduler, can have
multiple workers. In the latter, the default is \code{workers = NULL}, which
will resolve to \code{getOption("future.batchtools.workers")}. If that is not
specified, the value of environment variable \code{R_FUTURE_BATCHTOOLS_WORKERS}
will be used. If neither are specified, then the default is \code{100}.}
\item{registry}{(optional) A named list of settings to control the setup
of the batchtools registry.}
\item{\ldots}{Additional arguments passed to \code{\link[=BatchtoolsFuture]{BatchtoolsFuture()}}.}
}
\value{
An object of class \code{BatchtoolsFuture}.
}
\description{
A batchtools local future is an synchronous uniprocess future that
will be evaluated in a background R session.
A batchtools interactive future is an synchronous uniprocess future
that will be evaluated in the current R session (and variables will
be assigned to the calling environment rather than to a local one).
Both types of futures will block until the futures are resolved.
}
\details{
batchtools local futures rely on the batchtools backend set up by
\code{\link[batchtools:makeClusterFunctionsInteractive]{batchtools::makeClusterFunctionsInteractive(external = TRUE)}}
and batchtools interactive futures on the one set up by
\code{\link[batchtools:makeClusterFunctionsInteractive]{batchtools::makeClusterFunctionsInteractive()}}.
These are supported by all operating systems.
An alternative to batchtools local futures is to use
\link[future:cluster]{cluster} futures of the \pkg{future}
package with a single local background session, i.e.
\code{plan(cluster, workers = "localhost")}.
An alternative to batchtools interactive futures is to use
\link[future:sequential]{transparent} futures of the
\pkg{future} package.
}
\examples{
## Use local batchtools futures
plan(batchtools_local)
## A global variable
a <- 1
## Create explicit future
f <- future({
b <- 3
c <- 2
a * b * c
})
v <- value(f)
print(v)
## Create implicit future
v \%<-\% {
b <- 3
c <- 2
a * b * c
}
print(v)
}
|