% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/backend_api-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{\ldots}{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 there is no future backend specified after this one, 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{parallel::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/futureverse/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}
