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

vector<future<T> > does not work gracefully with dataflow, when_all and unwrapped #1126

Closed
brycelelbach opened this Issue May 5, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@brycelelbach
Member

brycelelbach commented May 5, 2014

// Assume these definitions throughout:
hpx::future<boost::uint64_t> T;
std::vector<hpx::future<double> > U;

// I want to be able to use vectors of futures as arguments to my continuations;
// the vectors of futures will not be the only arguments, however. This does not
// seem to work with HPX currently.

// cfl0; HPX-free call signature. Enables the use of existing "local" kernels
// (e.g. small grains of work which are highly optimized - stuff that we don't
// want to break down into smaller chunks). Facilitates integration with legacy
// code without interface changes; this is an important point for large, existing
// codebases.
double cfl0(boost::uint64_t step, std::vector<double> u)

// cfl1; Call signature I am currently able to use with when_all d 
double cfl1(boost::uint64_t step, std::vector<hpx::future<double> > U);

// Won't compile; when_all/dataflow do not take vectors of futures for the tuple 
// call signature. You can pass a vector of futures if it is the only argument; 
// otherwise things seem to break. 
when_all(step, u);
dataflow(unwrapped(cfl0, step, u);

// Won't work; the second argumenet passed to the continuation is a vector 
// of futures, not a vector of values.
when_all(step, when_all(u)).then(unwrapped(cfl0));
dataflow(unwrapped(cfl0), when_all(u));

// Won't work; the 'step' argument needs 1 level of unwrapping, and the 'U' 
// argument needs 2 levels of unwrapping. unwrapped() does not support 
// mixed levels of unwrapping.
when_all(step, when_all(u)).then(unwrapped2(cfl0));
dataflow(unwrapped2(cfl0), step, when_all(u));

// Works. Ugly. Forces me to use the cfl1 call signature (or write another
// wrapper - but that would be redundant since we have unwrapped). The 
// cfl1 signature is not acceptable, because it has an hpx::future in it; it is 
// not an "HPX free" call signture. 
when_all(step, when_all(u)).then(unwrapped(cfl1)); 
dataflow(unwrapped(cfl1), step, when_all(u));

// Another major limitation; we only take std::vectors. Why not std::list, or 
// arbitrary Containers. I feel like perhaps we need to go the Spirit route, to
// some degree; we need a (much simpler) attribute grammar, which 
// supports nested futures and containers of futures.

@hkaiser hkaiser added this to the 0.9.9 milestone May 5, 2014

@sithhell

This comment has been minimized.

Show comment
Hide comment
@sithhell

sithhell Jun 3, 2014

Member

This is closely related to #1132.

Member

sithhell commented Jun 3, 2014

This is closely related to #1132.

@hkaiser hkaiser closed this in 733a374 Aug 19, 2014

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 19, 2014

Member

Closed accidentally, reopening

Member

hkaiser commented Aug 19, 2014

Closed accidentally, reopening

@hkaiser hkaiser reopened this Aug 19, 2014

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

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Sep 26, 2014

Member

Part of the issues above could be resolved by allowing for unwrapped to 'ignore' non-future arguments (to pass those through).

Member

hkaiser commented Sep 26, 2014

Part of the issues above could be resolved by allowing for unwrapped to 'ignore' non-future arguments (to pass those through).

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Feb 25, 2015

Member

Moving this to the next milestone. This requires more discussions and decision making before it can be fixed.

Member

hkaiser commented Feb 25, 2015

Moving this to the next milestone. This requires more discussions and decision making before it can be fixed.

@hkaiser hkaiser modified the milestones: 1.0.0, 0.9.10 Feb 25, 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

@Naios Naios referenced this issue Sep 6, 2017

Merged

Implement an API for asynchronous pack traversal #2829

1 of 1 task complete
@msimberg

This comment has been minimized.

Show comment
Hide comment
@msimberg

msimberg Nov 21, 2017

Contributor

Is there something to be done here now that #2741 and #2829 are merged?

Contributor

msimberg commented Nov 21, 2017

Is there something to be done here now that #2741 and #2829 are merged?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Nov 21, 2017

Member

I think we can close this as the issue has been addressed by #2829.

Member

hkaiser commented Nov 21, 2017

I think we can close this as the issue has been addressed by #2829.

@hkaiser hkaiser closed this Nov 21, 2017

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