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 requery 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 API 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
immediateCondition:s in near real-time,
e.g. progression conditions signals 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.