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
|
% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/Future-class.R
\name{getExpression}
\alias{getExpression}
\alias{getExpression.Future}
\title{Inject code for the next type of future to use for nested futures}
\usage{
getExpression(future, ...)
}
\arguments{
\item{future}{Current future.}
\item{\dots}{Not used.}
}
\value{
A future expression with code injected to set what
type of future to use for nested futures, iff any.
}
\description{
Inject code for the next type of future to use for nested futures
}
\details{
If no next future strategy is specified, the default is to
use \link{sequential} futures. This conservative approach protects
against spawning off recursive futures by mistake, especially
\link{multicore} and \link{multisession} ones.
The default will also set \code{options(mc.cores = 1L)} (*) so that
no parallel \R processes are spawned off by functions such as
\code{\link[parallel:mclapply]{mclapply}()} and friends.
Currently it is not possible to specify what type of nested
futures to be used, meaning the above default will always be
used.
See \href{https://github.com/HenrikBengtsson/future/issues/37}{Issue #37}
for plans on adding support for custom nested future types.
(*) Ideally we would set \code{mc.cores = 0} but that will unfortunately
cause \code{mclapply()} and friends to generate an error saying
"'mc.cores' must be >= 1". Ideally those functions should
fall back to using the non-multicore alternative in this
case, e.g. \code{mclapply(...)} => \code{lapply(...)}.
See \url{https://github.com/HenrikBengtsson/Wishlist-for-R/issues/7}
for a discussion on this.
}
\keyword{internal}
|
