Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions xml/issue4339.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
<?xml version='1.0' encoding='utf-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="4339" status="New">
<title><code>task</code>'s coroutine frame may be released late</title>
<section><sref ref="[exec.task]"/></section>
<submitter>Dietmar Kühl</submitter>
<date>31 Aug 2025</date>
<priority>99</priority>

<discussion>
<p>
The specification of <code>task</code> doesn't spell out when the
coroutine frame is destroyed (i.e., when <code>handle.destroy()</code>
is called). As a result the lifetime of arguments passed to the
coroutine and/or of local variables in the coroutine body may be
longer than expected.
</p>
<p>
The intention is that the coroutine frame is destroyed before any
of the completion functions is called. One implication of this
requirement is that the result and error objects can't be stored
in the <code>promise_type</code> when the completion function is
called although the exposition-only members <code><i>result</i></code>
and <code><i>errors</i></code> imply exactly that. Instead the data
needs to be stored in the operation state object or it needs to be
moved to a different place before calling <code>destroy()</code>.
</p>
<p>
The proposed resolution is to add a paragraph to the specification
of <code>promise_type</code> in <sref ref="[task.promise]"/> that spells
out that the coroutine frame is destroyed before any of the completion
functions is called. To actually do that the exposition-only members
<code><i>result</i></code> and <code><i>errors</i></code> can't
remain as members of the <code>promise_type</code>. While writing
the relevant change it turned out that <code><i>errors</i></code>
is a <code>variant</code> which only ever stores an
<code>exception_ptr</code> (the other potential errors are immediately
reported via the awaiter return from <code>yield_value</code>).
Thus, the <code>variant</code> can be replaced with an
<code>exception_ptr</code>.
</p>
</discussion>

<resolution>
<p>
</p>
</resolution>

</issue>