UPCXX_BACKEND inside future1

[BrianS]

we should not be seeing this version of the wait function since the C-preprocessor should be seeing #ifdef UPCXX_BACKEND

  const int arg = 5;
  future<int> ans0 = 5;
  auto f_01 = make_future(ans0, arg);
  f_01.wait(); // compile error line future1.hpp:182, 

[john bachan]

I assume the code you posted would make for a reproducible case if wrapped in the minimal main() boilerplate?

Can you share the compiler line that was issued.

[BrianS]

yeah, wrap in main and the future header.

last line of compile

g++ -std=c++11 -D_GNU_SOURCE=1 -I/Users/bvs/upcxx/.nobs/art/6a1a13ad1d87f197b5e5b09120bfe569750cf430 -DUPCXX_ASSERT_ENABLED=0 -O0 -g -Wall -c /Users/bvs/upcxx_tmp/test/future_bug.cpp -o /Users/bvs/upcxx/.nobs/art/21e5e4822270a770be66f9d734ba04deae087314.future_bug.cpp.o

the future header does not pick up gasnet on it's own.

[john bachan]

I'm not sure what you're asserting as erroneous behavior. The future header does not force upcxx backend into the mix, it adapts to its presence globally either way. Without the backend's progress function, there is no sensible thing to do in the spin loop of wait() so it demands you provide a callable for it to call as the body of its spin loop. I have verified this behavior with the following test which works and breaks only as expected:

#include <upcxx/future.hpp>

#include <upcxx/backend.hpp> // Comment out to induce error below

int main() {
 using namespace upcxx;
 future<int> f = make_future(1);
 f.wait(); // ERROR iff include commented-out: Candidate expects 1 argument, 0 provided
}

Does your example agree or disagree with my example? Are you still sure you've found a bug or is this just a grievance with the code's intended behavior? I could use some more context to help me understand your point.

[BrianS]

I think you are right. future is agnostic about the progress engine, just that one needs to exist. Perhaps we should be calling this out in the spec in the future API section?

[john bachan]

I think if/when we want to fully decouple future from the upcxx spec then it would be appropriate to raise the issue. For now we have a spec that tightly couples (but only through this one call, wait), and an implementation that gracefully decouples for the purposes of unit testing. That seems reasonable.