co_await 似乎不是最理想的？

Question

我有一个异步函数

void async_foo(A& a, B& b, C&c, function<void(X&, Y&)> callback);

我想在stackless协程中使用它所以我写

auto coro_foo(A& a, B& b, C& c, X& x) /* -> Y */ {
  struct Awaitable {
    bool await_ready() const noexcept { return false; }
    bool await_suspend(coroutine_handle<> h) {
      async_foo(*a_, *b_, *c_, [this, h](X& x, Y& y){
        *x_ = std::move(x);
        y_ = std::move(y);
        h.resume();
      });
    }
    Y await_resume() {
      return std::move(y);
    }
    A* a_; B* b_; C* c_; X* x_; Y y_;
  };
  return Awaitable{&a, &b, &c, &x};
}

那我就可以这样用了:

Y y = co_await coro_foo(a, b, c, x);

编译器会将其重写为：

  auto e = coro_foo(a, b, c, x);
  if (!e.await_ready()) {
    <suspend>
    if (e.await_suspend(h)) return;
resume-point:
    <resume>
  }
  Y y = e.await_resume();

有了这个，协程将在挂起时保留 a_、b_ 和 c_，当它只需要保留它们直到我们得到 coroutine_handle await_suspend(h).
（顺便说一句，我不确定我是否可以在此处保留对参数的引用。）

如果wrapper函数可以直接获取coroutine_handle作为参数，效率会高很多

这可能是一个隐式参数：

Promise f(coroutine_handle<> h);
co_await f();

或者它可以是一个特殊的关键字参数：

Promise f(coroutine_handle<> h);
f(co_await);

我是不是漏掉了什么？（其他的开销不是那么大。）

Answer 1

Coroutine TS 定义的 "coroutine" 系统旨在处理异步功能：

Return 类似未来的对象（表示延迟 return 值的对象）。
类未来对象能够与延续函数相关联。

async_foo 不满足这些要求。它不是 return 类似未来的对象；它 "returns" 通过延续函数的值。并且此延续作为参数传递，而不是您对对象的 return 类型执行的操作。

到 co_await 完全发生时，生成未来的潜在异步过程预计已经开始。或者至少，co_await 机制使它 有可能 开始。

您建议的版本失去了 await_ready 功能，该功能允许 co_await 处理潜在的异步进程。在生成未来和调用 await_ready 之间，该过程可能已经完成。如果有，则无需安排协程的恢复。因此，它应该发生在这个线程上。

如果堆栈的低效率问题困扰着您，那么您将不得不按照 Coroutine TS 要求的方式做事。

处理此问题的一般方法是 coro_foo 直接执行 async_foo 和 return 一个具有 .then 机制的类未来对象。你的问题是 async_foo 本身没有类似 .then 的机制，所以你必须创建一个。

这意味着 coro_foo 必须传递 async_foo 一个存储 coroutine_handle<> 的函子，该函子可以通过未来的延续机制进行更新。当然，您还需要同步原语。如果在执行仿函数时句柄已经初始化，则仿函数调用它，恢复协程。如果仿函数在没有恢复协程的情况下完成，仿函数将设置一个变量让等待机器知道该值已准备就绪。

由于句柄和此变量在 await 机制和仿函数之间共享，因此您需要确保两者之间的同步。这是一件相当复杂的事情，但它是 .then 式机器所需要的。

或者你可以忍受轻微的低效率。

Answer 2

async_foo 可以直接从 coro_foo 调用，如果我们使用类似未来的 class.
这将花费我们一次分配和一个原子变量：

static char done = 0;

template<typename T>
struct Future {
  T t_;
  std::atomic<void*> addr_;

  template<typename X>
  void SetResult(X&& r) {
    t_ = std::move(r);
    void* h = addr_.exchange(&done);
    if (h) std::experimental::coroutine_handle<>::from_address(h).resume();
  }

  bool await_ready() const noexcept { return false; }
  bool await_suspend(std::experimental::coroutine_handle<> h) noexcept {
    return addr_.exchange(h.address()) != &done;
  }
  auto await_resume() noexcept {
    auto t = std::move(t_);
    delete this;  // unsafe, will be leaked on h.destroy()
    return t;
  }
};

Future<Y>& coro_foo(A& a, B& b, C& c, X& x) {
  auto* p = new Future<Y>;
  async_foo(a, b, c, [p, &x](X& x_, Y& y_) {
        x = std::move(x_);
        p->SetResult(y_);
  });
  return *p;
}

看起来不是很贵，
但它并没有显着改善问题中的代码。
（也很伤眼睛）

Answer 3

当前设计有一个重要的未来，co_await 采用通用表达式而不是调用表达式。

这让我们可以这样写代码：

auto f = coro_1();
co_await coro_2();
co_await f;

我们可以运行两个或多个并行的异步任务，然后等待它们。

因此，coro_1 的实现应该在它的调用中开始工作，而不是在 await_suspend 中。

这也意味着应该有一个预分配的内存，其中 coro_1 将放置其结果，并将 coroutine_handle.

放置在该位置

我们可以使用不可复制的Awaitable并保证复制省略。
async_foo 将从 Awaitable:

的构造函数调用

auto coro_foo(A& a, B& b, C& c, X& x) /* -> Y */ {
  struct Awaitable {
    Awaitable(A& a, B& b, C& c, X& x) : x_(x) {
      async_foo(a, b, c, [this](X& x, Y& y){
        *x_ = std::move(x);
        y_ = &y;
        if (done_.exchange(true)) {
          h.resume();  // Coroutine resumes inside of resume()
        }
      });
    }
    bool await_ready() const noexcept {
      return done_;
    }
    bool await_suspend(coroutine_handle<> h) {
      h_ = h;
      return !done_.exchange(true);
    }
    Y await_resume() {
      return std::move(*y_);
    }
    atomic<bool> done_;
    coroutine_handle<> h_;
    X* x_;
    Y* y_;
  };
  return Awaitable(a, b, c, &x);
}

co_await 似乎不是最理想的？

co_await appears to be suboptimal?

c++

c++-coroutine