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

Support queue of future fulfillments in flux futures + other structural improvements #1610

Merged
merged 6 commits into from Jul 27, 2018

Conversation

Projects
None yet
3 participants
@chu11
Copy link
Contributor

commented Jul 27, 2018

The PR handles the issues discussed in #1589. A summary.

  • Refactor futures so that values (e.g. msgs) and errors are both valid fulfillments (or "results") of a future.
  • Support the concept of a "fatal error" in futures, in which such an error takes precedence over any other results in a future. This is set via the flux_future_fatal_error() function. This allows catastrophic errors to be set and reported to a user.
  • Support an optional "error string" in any error fulfilled in a future. This error string can give additional information to a user on where an error came from. For example, if an EPROTO error occured, an error string of "client" or "server" could be set to differentiate where it occurred from. The string can be retrieved with flux_future_error_string().
    • Due to the "error string" support, remove flux_rpc_get_error().
  • Support a queue in each future that allows multiple "results" to be queued and returned to the user in FIFO order. This allows multiple messages, errors, etc. to be returned to a user. The queue implementation also solves any race issues that may occur if the fulfiller of a future is faster than the reader of a future.

chu11 added some commits Jul 26, 2018

libflux/future: Refactor result vs errnum logic
Internally in future, store both a "result" and a "errnum"
fulfillment in a single result data structure.
libflux/future: Add new flux_future_fatal_error()
New function will allow callers to set a "fatal error" in a
future, an error that overrides all prior future results.
common/libflux: Add error strings to futures
When errors are fulfilled in a flux future, optionally allow
the user to set an error string, which can be retrieved later
via the new function flux_future_error_string().
libflux/rpc: Refactor savings of rpc error string
With support of error strings in flux futures, do not save
an rpc error in a future's aux hash, instead save it in the
future's error result, which users can retrieve later via
flux_future_error_string().
libflux/rpc: Remove flux_rpc_get_error()
With support for flux_future_error_string(), there is no longer
a need for flux_rpc_get_error().
libflux/future: Add future result queueing
Support the ability to queue multiple results or errors into a single
future via a queue.  This removes any potential race conditions
that may occur if streams of results are fulfilled more quickly than
they can be read by users.

Fixes #1589
@coveralls

This comment has been minimized.

Copy link

commented Jul 27, 2018

Coverage Status

Coverage increased (+0.03%) to 79.546% when pulling 677910a on chu11:issue1589 into 768eb48 on flux-framework:master.

@grondo

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2018

LGTM! Thanks for even updating the docs.

@grondo

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2018

Restarted a build that died with our friend: write error

@chu11

This comment has been minimized.

Copy link
Contributor Author

commented Jul 27, 2018

restarted a builder that hit #1150

@grondo grondo merged commit 90f05e9 into flux-framework:master Jul 27, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.03%) to 79.546%
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.