
Check whether a future is resolved or not
Source:R/backend_api-11.ClusterFutureBackend-class.R
, R/backend_api-11.MulticoreFutureBackend-class.R
, R/backend_api-Future-class.R
, and 1 more
resolved.Rd
Check whether a future is resolved or not
Usage
# S3 method for class 'ClusterFuture'
resolved(x, run = TRUE, timeout = NULL, ...)
# S3 method for class 'MulticoreFuture'
resolved(x, run = TRUE, timeout = NULL, ...)
# S3 method for class 'Future'
resolved(x, run = TRUE, ...)
resolved(x, ...)
# Default S3 method
resolved(x, ...)
# S3 method for class 'list'
resolved(x, ...)
# S3 method for class 'environment'
resolved(x, ...)
Arguments
- x
A Future, a list, or an environment (which also includes list environment).
- run
(logical) If TRUE, any lazy futures is launched, otherwise not.
- timeout
(numeric) The maximum time (in seconds) for polling the worker for a response. If no response is available within this time limit, FALSE is returned assuming the future is still being processed. If NULL, the value defaults to
getOption("future.<type>.resolved.timeout")
, thengetOption("future.resolved.timeout")
, and finally 0.01 (seconds), where<type>
corresponds to the type of future, e.g.cluster
andmulticore
.- ...
Not used.
Value
A logical vector of the same length and dimensions as x
.
Each element is TRUE unless the corresponding element is a
non-resolved future in case it is FALSE.
The default method always returns TRUE.
Details
Checking a lazy future, triggers it to be launched, unless run = FALSE
.
resolved()
methods must always return TRUE
or FALSE
values, must
always launch lazy futures by default (run = TRUE
), and must never block
indefinitely. This is because it should always be possible to poll futures
until they are resolved using resolved()
, e.g.
while (!all(resolved(futures))) Sys.sleep(5)
.
Each future backend must implement a resolved()
method that returns
either TRUE or FALSE, or throw a FutureError (which indicate a
significant, often unrecoverable infrastructure problem, or an interrupt).
Behavior of cluster and multisession futures
resolved()
will always attempt to launch a lazy future, if possible.
If all worker slots are occupied, resolved()
for ClusterFuture
and
MultisessionFuture
will attempt to free one up by checking whether
one of the futures is resolved. If it is, then its result is collected
in order to free up one worker slot.
resolved()
for ClusterFuture
may receive immediate condition objects, rather
than a FutureResult, when polling the worker for results. In such cases, the
condition object is collected and another poll it performed. Up to 100 immediate
conditions may be collected this way per resolved()
call, before considering
the future non-resolved and FALSE being returned.
Behavior of multicore futures
resolved()
for MulticoreFuture
may receive immediate condition objects, rather than a
FutureResult, when polling the worker for results. In such cases, all such condition
objects are collected, before considering the future non-resolved and FALSE being returned.