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)
}
|
