I don't quite understand how fork works

[QuarticCat]

After fork_awaitable::await_suspend being called, the parent task will be pushed to WSQ, and then the function continues to resume the child task. But before the first suspension of the child task, the state of the parent task has not been changed to the next one yet. While at this timepoint, the parent task can be stolen because it's in WSQ already. If another worker steals the parent task and resumes it, the resume function will not start from the state after co_await fork. Am I wrong?

[ConorWilliams]

I don't fully follow your question but I'll do my best to answer, please ask if you need more clarification:

After fork_awaitable::await_suspend being called, the parent task will be pushed to WSQ, and then the function continues to resume the child task.

It is the executing thread that resumes the child task.

But before the first suspension of the child task, the state of the parent task has not been changed to the next one yet. While at this timepoint, the parent task can be stolen because it's in WSQ already.

In fork_awaitable::await_suspend both the parent and the child tasks are suspended. A handle to the parent (which will resume just after the fork call) is puched to the executors WSQ.

If another worker steals the parent task and resumes it, the resume function will not start from the state after co_await fork. Am I wrong?

Yes, you are wrong, the stolen continuation (of the parent) will resume after the fork.

[QuarticCat]

According to the expansion of cppinsights in this example, invocation of await_suspend is before the assignment of __suspend_index. So just after tls::context()->push, the __suspend_index is still unchanged, while at this timepoint another thread can steal and resume the parent.

[ConorWilliams]

Cpp reference says:

Then, awaiter.await_ready() is called (this is a short-cut to avoid the cost of suspension if it's known that the result is ready or can be completed synchronously). If its result, contextually-converted to bool is false then

The coroutine is suspended (its coroutine state is populated with local variables and current suspension point).
awaiter.await_suspend(handle) is called, where handle is the coroutine handle representing the current coroutine. Inside that function, the suspended coroutine state is observable via that handle, and it's this function's responsibility to schedule it to resume on some executor, or to be destroyed (returning false counts as scheduling)

I expect there could be several reasons for the the observation you see:

• The index is being set for the next suspend point not the current one.
• Optimisations are obfuscating your code, a smart compiler could see that nothing is done with the handle and that it safe to defer the increment (or not do it at all)
• Your code contains multiple UB: non-void functions must terminate with a return.

[QuarticCat]

That makes sense. Thank you for you answers!