Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relaunching a future: some notes #205

Open
HenrikBengtsson opened this issue Mar 11, 2018 · 0 comments
Open

Relaunching a future: some notes #205

HenrikBengtsson opened this issue Mar 11, 2018 · 0 comments
Labels
enhancement feature request feature/restart Frontend API Part of the Future API that users of futures rely on

Comments

@HenrikBengtsson
Copy link
Owner

HenrikBengtsson commented Mar 11, 2018

Background

Being able to relaunch a future, that is re-evaluate a future expression that has already been evaluated in full or partially due to a failure, is useful when for instance the communication between master and worked failed. See Issues #154 and #188 for examples of such needs.

Implications

However, introducing the possibility to relaunch a future requires that the original state can be reproduced including global variables, which is currently not recorded for 'sequential' and 'multicore' futures when using lazy = FALSE. In other words, this addition to the Future API introduces implications on the contract that future backends needs to adhere to.

Moreover, not all R expression can be re-evaluated, e.g. maybe a mutable object has been changed or a resource such as a the buffer of a read connection has been consumed. This suggests that we need a way to indicated whether an R expression can be re-evaluated or not, and if so, what should be the default. An alternative approach is to ignore this constraint and simply rely on the caller (the code that orchestrates the futures to handle such problems) - which also means that each of those will implement there own solution which is less ideal.

Another question to be asked is whether we can assume all backends support re-evaluation or not. Maybe "re-launchability" should be an optional feature of a future, cf. Issue #172 (DESIGN: Future API - Minimal/Essential API and Extended/Optional API).

Prototype

Ignoring all of the above complications, it's quite easy to relaunch a future. All that is needed is to reset the future (drop all collected results/values and reset the internal "state") and then relaunch it. None of this is part of the public frontend API - just wanted to say that the actually resetting part is easy. It's all of the above that holds us back from adding support for relaunching a (failed) future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement feature request feature/restart Frontend API Part of the Future API that users of futures rely on
Projects
None yet
Development

No branches or pull requests

1 participant