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

Merge different utilities that wait on futures #1132

Open
K-ballo opened this Issue May 12, 2014 · 2 comments

Comments

Projects
None yet
4 participants
@K-ballo
Member

K-ballo commented May 12, 2014

We have a number of different utilities that wait on futures. Each implements their own callbacks to wait on future completion. We should make a single generic implementation that works for all of them.

Some of those utilities are: dataflow, wait_all, when_all, invoke_when_ready, unwrapped.

@sithhell

This comment has been minimized.

Show comment
Hide comment
@sithhell

sithhell May 12, 2014

Member

Am 12.05.2014 16:57 schrieb "Agustín Bergé" notifications@github.com:

We have a number of different utilities that wait on futures. Each
implements their own callbacks to wait on future completion. We should make
a single generic implementation that works for all of them.

Some of those utilities are: dataflow, wait_all, when_all,
invoke_when_ready, unwrapped.

In addition, it should get decided if we call it "dataflow" or
"invoke_when_ready" as they do exactly the same once this generic facility
is in place.

Member

sithhell commented May 12, 2014

Am 12.05.2014 16:57 schrieb "Agustín Bergé" notifications@github.com:

We have a number of different utilities that wait on futures. Each
implements their own callbacks to wait on future completion. We should make
a single generic implementation that works for all of them.

Some of those utilities are: dataflow, wait_all, when_all,
invoke_when_ready, unwrapped.

In addition, it should get decided if we call it "dataflow" or
"invoke_when_ready" as they do exactly the same once this generic facility
is in place.

@sithhell

This comment has been minimized.

Show comment
Hide comment
@sithhell

sithhell Jun 12, 2014

Member

While thinking about this, I am getting more and more to the conclusion that async, dataflow, invoke_when_ready and apply should be merged alltogether into async and apply. This won't break semantics of async and would simplify the API in the sense that users only have to remember two functions to (asynchronously) start tasks.
I propose to reuse hpx::util::protect (or something similar) to "protect" the delay of future arguments until the task gets executed and therefor bypassing the dataflow mechanism

Member

sithhell commented Jun 12, 2014

While thinking about this, I am getting more and more to the conclusion that async, dataflow, invoke_when_ready and apply should be merged alltogether into async and apply. This won't break semantics of async and would simplify the API in the sense that users only have to remember two functions to (asynchronously) start tasks.
I propose to reuse hpx::util::protect (or something similar) to "protect" the delay of future arguments until the task gets executed and therefor bypassing the dataflow mechanism

@hkaiser hkaiser modified the milestones: 0.9.10, 0.9.9 Sep 13, 2014

@hkaiser hkaiser modified the milestones: 1.0.0, 0.9.10 Feb 26, 2015

@hkaiser hkaiser modified the milestones: 1.0.0, 1.1.0 Apr 23, 2017

Naios added a commit to Naios/hpx that referenced this issue Jul 24, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

Naios added a commit to Naios/hpx that referenced this issue Jul 24, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

Naios added a commit to Naios/hpx that referenced this issue Jul 25, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

Naios added a commit to Naios/hpx that referenced this issue Jul 25, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

Naios added a commit to Naios/hpx that referenced this issue Jul 25, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

Naios added a commit to Naios/hpx that referenced this issue Jul 27, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132

@msimberg msimberg removed this from the 1.1.0 milestone Dec 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment