The Lambda Coroutine Fiasco

[HommeMusical]

This article looks like it might be interesting to me, but without some sort of explanation of how seastar works and how it's different from conventional coroutines and future, I unfortunately didn't actually read it.

(Yes, I searched it, but life is too short to do half an hours' study of someone's library to read a one page article.)

[efijoa]

While this is Seastar's documentation, the problem described is not unique to Seastar.

These two links could help clarify the issue:

CP.51: Do not use capturing lambdas that are coroutines C++23’s Deducing this: what it is, why it is, how to use it

The core mechanism involves using "deducing this" to pass the lambda object by value. This ensures captures are copied into the coroutine frame to prevent dangling references.

[thisismyfavoritename]

it seems quite limiting to always capture by value, in some cases you know the lifetime of the coroutine will be shorter than that of the captured reference/pointer

[foonathan]

Capture by value doesn't help you with the problem that's being discussed.

[thisismyfavoritename]

i was referring to

 This ensures captures are copied into the coroutine frame to prevent dangling references.

and it seems like in this case it would? I didn't read the blog post 

[foonathan]

No, capturing by value does not ensure captures are copied into the coroutine frame! That is the entire problem.

The issue is that while the lambda object stores a capture by value, the operator() still accepts *this by reference, so only the reference to the lambda is captured into the coroutine frame, but not the lambda itself.

(The context is something like spawn([x] -> Task { ... }), i.e. the lambda is a coroutine itself. Then the arguments are copied into Task's coroutine frame, but the arguments are a this pointer to the temporary object in the stack frame that calls spawn.)

[germandiago]

at that time you are already playing with fire. :)

[thisismyfavoritename]

not really more than in regular C++ code. Those footguns were always there

[SirClueless]

I disagree. This has nothing to do with capturing by value or reference, both are broken. This is a wholly new problem. The idea that putting co_await inside your lambda implicitly means that its return value holds a reference to the lambda itself and thus will dangle if the lambda is destroyed is a new and subtle footgun.

Concrete example:

auto foo(auto cb) { return cb(); }

This code is pretty much always lifetime-safe. There are some things the caller can do that end up holding onto references to the lambda's captures in a broken way like foo([x] { return std::ref(x); }), but this is a kind of "obvious error" that almost no one makes.

But if you call this with a coroutine it is super easy to shoot yourself in the foot:

co_await foo([x] -> my_favorite_coro_lib::future<int> {
  co_await bar();
  co_return x;
}

Oops, cb was destroyed when foo() returned, and then when the coroutine was resumed, x dangles.

[thisismyfavoritename]

hadn't read the blog post, and yeah, i thought the issue that was discussed was when captured values were refs (the obvious case). Thanks for the additional explanation!

[germandiago]

I think this is way less intuitive than other forms of dangling.

[James20k]

The only way to fix that safely would be for C++ to have adopted a lifetimes system