help("mirai_cluster", package = "future.mirai").If a mirai future that was terminated abruptly (e.g. via
tools::pskill() or by the operating system), then it was
not detected as such. Instead it resulted in an unexpected error that
could not be recovered from. Now it is detected and a
FutureInterruptError is signaled, which can then be handled
and the future may be reset().
result() on an interrupted mirai future would only
throw FutureInterruptError the first time. Succeeding calls would result
in other errors.
resolved() on a mirai future already known to be
interrupted would re-query the mirai object, instead of returning TRUE
immediately.
Now ‘mirai’ futures can be canceled using cancel(),
which also interrupts them by default, which in turn frees up compute
resources sooner. Map-reduce APIs such as future.apply,
doFuture, and furrr can take advantage
of this by canceling all non-resolved futures whenever they detect an
error in one of the futures. Also, canceled futures can be
reset() and thereafter relaunched, possibly on another
future backend.
Now ‘mirai_multisession’ futures relay
immediateConditions in near real-time,
e.g. progression conditions signaled by the
progressr package.
mirai::daemons() argument resilience is
being removed.nbrOfWorkers() and nbrOfFreeWorkers() did
not handle mirai dispatcher errors. Because those are integers, these
functions would return the error integer value instead of giving a
FutureError.
Need a high-speed mirror for your open-source project?
Contact our mirror admin team at info@clientvps.com.
This archive is provided as a free public service to the community.
Proudly supported by infrastructure from VPSPulse , RxServers , BuyNumber , UnitVPS , OffshoreName and secure payment technology by ArionPay.