bugaevc

bugaevc, 11 days ago

@tbernard LLM? 😟

bugaevc, 18 days ago

@zhuowei CVE-2024-3401 (Taylor's version)

bugaevc, 25 days ago

@nnethercote I misread FREEBIRD as FREEBSD 😁

bugaevc, 28 days ago

@brooke useless use of cat!

bugaevc, 30 days ago

@alice I'm guessing there's no public API to get a color variable's value for a widget programmatically, is there? Basically I'd want something like the existing Widget::get_color, but with a name argument.

bugaevc, 1 month ago

The perfect cover does not exi...

https://youtu.be/-gR9CpmEU7c

bugaevc, 1 month ago

The final suspend should really suspend the coroutine (so std::suspend_never won't do), perhaps notify someone that the coroutine is done, maybe post its return value somewhere (perhaps resume another coroutine that's co_await'ing...), and finally destroy the coroutine frame by calling handle.destroy(). It then returns, just like any other suspension point, to the last resumer (or the original caller, if the coroutine never suspended on any other suspension points).

bugaevc, 1 month ago

Finally, it calls .final_suspend() on the promise (which must be noexcept, since it's too late to throw exceptions at this point) and co_await's the returned value. This mirrors the .initial_suspend() at the start.

bugaevc, 1 month ago

When the coroutine completes, it either:

• calls promise.return_value(value), for 'co_return expr();',
• calls promise.return_void(), for 'co_return;' (or simply reaching the end of body),
• calls promise.unhandled_exception() if it terminates by throwing an exception that it doesn't itself catch (notably, the exception doesn't fall out of the coroutine to the resumer).

In the implementation of these, you'd want to save the return value (or the exception info) somewhere, to be retrieved later.

bugaevc, 1 month ago

From that first suspension on, the coroutine can be resumed via its handle. Whether you're expecting that to be done by the caller (and the return object holds a copy of the coroutine handle) or by whatever the coroutine is suspended on co_await'ing, is up to your design; both options are possible.

As said, std::coroutine_handle<> is a non-owning pointer; also resuming a completed or already running coroutine is UB. This is naturally a ripe area for ownership / UaF / memory unsafety issues.

bugaevc, 1 month ago

Whether the coroutine suspends immediately on .initial_suspend(), or runs to its first real suspension point and suspends there, this is where it returns to the caller, and the value that it returns is the object created earlier with .get_return_object(). Once again, the caller may not even know that it's a coroutine that it has invoked, from its perspective it's just another function with a return value.

bugaevc, 1 month ago

So, we have figured out what the promise type for a coroutine is, based on its signature. The first thing a coroutine does when invoked is it allocates (almost certainly, on the heap) its frame, which includes among other things an instance of the promise type. It then initializes the instance of the promise type, either with its default constructor, or with a constructor taking (a copy of) all of the coroutine's arguments.

bugaevc, 1 month ago

The default implementation provides one specialization, which has promise_type = Ret::promise_type, meaning that if your coroutine's return type has a nested typename promise_type, that will be the promise type of the coroutine, unless you define your own specialization. This is meant for types like MyTask<T> or MyFuture<T> that are intended to be used as coroutines' return types.

bugaevc, 1 month ago

The "promise type" is not explicit in the signature or implementation of a coroutine. It is determined from the signature: for a coroutine with signature Ret(Arg1, Arg2, Arg3), the "promise type" used is whatever typename std::coroutine_traits<Ret, Arg1, Arg2, Arg3>::promise_type is; you can define your own specializations to make it be your intended promise type.

bugaevc, 1 month ago

When a function is implemented as a coroutine (because it contains co_ statements in its body), there is an important type that determines things about how it behaves, called the "promise type". Now, this is an example of very unfortunate naming, since this type has nothing to do with the notion of promise objects (aka futures or deferreds), nor with the existing std::promise<> type. A "coroutine policy type" or just "coroutine type" would have been a much better name, but it is what it is.

bugaevc, 1 month ago

Now that we looked at suspending and resuming, let's see how a coroutine gets created in the first place.

You cannot tell from a signature alone whether a function is implemented as a coroutine or not (i.e. whether it has any co_ statements in its body). An external library could flip a function implementation between coroutine / not coroutine without breaking API or ABI. The code to invoke it on the caller side is the same, and you get back an instance of the return type in both cases.

bugaevc, 1 month ago

There are a few knobs to this mechanism: you must also define bool .await_ready() that says whether the coroutine should suspend at all, and .await_suspend() can return a boolean or another coroutine handle to tail-resume in stead of void; also, you can override things to transform the operand of co_await, first into an "awaitable", and then into an "awaiter", and that's what the .await_*() methods would actually get called on (this is somewhat like IntoFuture, if you're keeping track).

bugaevc, 1 month ago

A coroutine suspends by co_await'ing an awaitable value.

Specifically, it calls the .await_suspend(std::coroutine_handle<>) method on it, passing a handle to itself. The method should store the handle somewhere and arrange for something to call .resume() on it later, when the awaited value "is ready". For example, it could arrange for handle.resume() to be called by another thread, or in a later iteration of an event loop.

bugaevc, 1 month ago

First thing: any function using any of co_return/co_await/co_yield in its body is a coroutine.

A coroutine can suspend its execution, saving its state into a "coroutine frame" (that's almost definitely heap-allocated), to be resumed later. std::coroutine_handle<> is a small wrapper around a pointer to a coroutine frame. It doesn't imply any ownership, can be cheaply copied around, and can be converted to a raw pointer and back using .address()/::from_address().

bugaevc, 1 month ago

3. You cannot just write code with it! For instance you cannot write something like this:

int async_callee() {
co_return 42;
}
int async_caller() {
int a = co_await async_callee();
co_return a + 35;
}

No, you need a bunch of library code/abstractions (that the standard library does not even provide!) to make something like that expressible.

bugaevc, 1 month ago

2. C++ 20 coroutines are just way overdesigned.

People say that the Rust async/await design is complicated (futures, tasks, polling, wakers, pinning, oh my!), but compared to C++ 20 coroutines, Rust design is quite straightforward.

bugaevc, 1 month ago

Let me start by criticizing the C++ 20 design, compared to, say, async/await in Rust:

1. Contrary to the famous C++ "zero overhead" principle, using coroutines pretty much requires pervasive heap allocations and indirect function calls.