Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129125
Content-Type: multipart/alternative;
 boundary="------------DMf0M0lXPeyoYIyx4OI8Gs6f"
Message-ID: <e30d3b54-7e6f-4932-b48a-d97b104da44c@gmail.com>
Date: Fri, 7 Nov 2025 02:24:27 -0300
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
Subject: [PHP-DEV] Re: PHP True Async RFC Stage 5
Content-Language: pt-BR
 <luisvscbarros@gmail.com>
From: luisvscbarros@gmail.com (=?UTF-8?Q?Lu=C3=ADs_Vin=C3=ADcius_Santos_da_Costa_Barros?=)

This is a multi-part message in MIME format.
--------------DMf0M0lXPeyoYIyx4OI8Gs6f
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Edmond,

First of all, sorry for my bad English, and thanks a lot for the huge 
amount of work you’ve put into this proposal.
You researched, wrote the RFC, implemented it, and answered tons of 
questions. Really impressive.

I have one suggestion and two small questions.

*Suggestion:*

Maybe keep the base /Awaitable/ internal and expose two userland 
interfaces that match the two cases described in the RFC:
|
// Single state change, idempotent read, same result on each await
interface Future extends Awaitable {}

// Multiple state changes, each await may observe a new state
interface Streamable extends Awaitable {}
This makes the single-shot vs multi-shot difference explicit and easier 
for tools and libraries to reason about.
|
*Questions (self-cancellation)*

1. What happens here?

|use function Async\spawn;
use function Async\suspend;

$coroutine = spawn(function() use (&$coroutine) {
     $coroutine->cancel(new \Async\CancellationError("Self-cancelled"));
     echo "Before suspend\n";
     suspend();
     echo "After suspend\n"; // should this run?
     return "completed";
});

|

|await($coroutine);|

Can a cancelled coroutine suspend?
And if a function that yields is called after the cancel, should that 
suspension still happen?

2. And what about this one?

|use function Async\spawn;

$coroutine2 = spawn(function() use (&$coroutine2) {
     $coroutine2->cancel(new \Async\CancellationError("Self-cancelled"));
     echo "Before exception\n";
     throw new \RuntimeException("boom after cancel");
});

|

|await($coroutine2);|

Which error does await() throw in this case — CancellationError or 
RuntimeException?

It’d be great to clarify that in the docs, since it affects where people 
put cleanup, logging, etc.


Again, thanks for the work, especially on such an important feature for 
PHP’s future.
Hope to see it in php-src soon.


Best,
Luís Vinícius

On Thu, 30 Oct 2025 08:19:40 +0000, Edmond Dantes wrote:

 > Hi
 >
 > 1.5 RFC:
 > https://wiki.php.net/rfc/true_async
 >
 > Here’s the fifth version of the RFC with the updates made after the
 > 1.4 discussion.
 >
 > Starting from 2025-11-03, there will be a two-week discussion period.
 >
 > **Changelog:**
 >
 > * Added FutureLike interface methods: cancel(), isCompleted(), 
isCancelled()
 > * Renamed Coroutine::isFinished() to Coroutine::isCompleted()
 > * Clarified exit/die behavior: always triggers Graceful Shutdown mode
 > regardless of where called
 > * Added rationale for “Cancellable by design” policy: explains why
 > default cancellability reduces code complexity for read-heavy PHP
 > workloads
 > * RFC structure improvements: reorganized Cancellation section with
 > proper subsections hierarchy
 > * Moved “Coroutine lifetime” as subsection under Coroutine section
 > * Extended glossary with Awaitable, Suspension, Graceful Shutdown, and
 > Deadlock terms
 > * Introduced FutureLike interface with single-assignment semantics and
 > changed await() signature to accept FutureLike instead of Awaitable
 > for type safety
 > * Split RFC: Moved Scope and structured concurrency functionality to
 > separate Scope RFC. Base RFC now focuses on core async primitives
 > (coroutines, await, cancellation)
 >
 > I decided not to wait until Monday and made the changes today. If
 > anyone has read version 1.4 and has comments on it, they’re still
 > relevant.
 >
 > The Scope API has been moved to a separate RFC:
 > https://wiki.php.net/rfc/true_async_scope
 >
 > ----
 > Best Regards, Ed

--------------DMf0M0lXPeyoYIyx4OI8Gs6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi Edmond,<br>
    <br>
    First of all, sorry for my bad English, and thanks a lot for the
    huge amount of work you’ve put into this proposal.<br>
    You researched, wrote the RFC, implemented it, and answered tons of
    questions. Really impressive.<br>
    <br>
    I have one suggestion and two small questions.<br>
    <br>
    <b>Suggestion:</b><br>
    <br>
    Maybe keep the base <i>Awaitable</i> internal and expose two
    userland interfaces that match the two cases described in the RFC:<br>
    <code><br>
      // Single state change, idempotent read, same result on each await<br>
      interface Future extends Awaitable {}<br>
      <br>
      // Multiple state changes, each await may observe a new state<br>
      interface Streamable extends Awaitable {}<br>
      This makes the single-shot vs multi-shot difference explicit and
      easier for tools and libraries to reason about.<br>
    </code><br>
    <b>Questions (self-cancellation)</b><br>
    <br>
    1. What happens here?<br>
    <br>
    <code>use function Async\spawn;<br>
      use function Async\suspend;<br>
      <br>
      $coroutine = spawn(function() use (&amp;$coroutine) {<br>
          $coroutine-&gt;cancel(new
      \Async\CancellationError("Self-cancelled"));<br>
          echo "Before suspend\n";<br>
          suspend();<br>
          echo "After suspend\n"; // should this run?<br>
          return "completed";<br>
      });<br>
      <br>
    </code>
    <p><code>await($coroutine);</code></p>
    Can a cancelled coroutine suspend?<br>
    And if a function that yields is called after the cancel, should
    that suspension still happen?<br>
    <br>
    2. And what about this one?<br>
    <br>
    <code>use function Async\spawn;<br>
      <br>
      $coroutine2 = spawn(function() use (&amp;$coroutine2) {<br>
          $coroutine2-&gt;cancel(new
      \Async\CancellationError("Self-cancelled"));<br>
          echo "Before exception\n";<br>
          throw new \RuntimeException("boom after cancel");<br>
      });<br>
      <br>
    </code>
    <p><code>await($coroutine2);</code></p>
    Which error does await() throw in this case — CancellationError or
    RuntimeException?<br>
    <p>It’d be great to clarify that in the docs, since it affects where
      people put cleanup, logging, etc.</p>
    <p><br>
    </p>
    Again, thanks for the work, especially on such an important feature
    for PHP’s future.<br>
    Hope to see it in php-src soon.<br>
    <br>
    <br>
    Best,<br>
    Luís Vinícius<br>
    <br>
    <p>On Thu, 30 Oct 2025 08:19:40 +0000, Edmond Dantes wrote:</p>
    &gt; Hi
    <br>
    &gt; <br>
    &gt; 1.5 RFC:
    <br>
    &gt; <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/true_async">https://wiki.php.net/rfc/true_async</a>
    <br>
    &gt; <br>
    &gt; Here’s the fifth version of the RFC with the updates made after
    the
    <br>
    &gt; 1.4 discussion.
    <br>
    &gt; <br>
    &gt; Starting from 2025-11-03, there will be a two-week discussion
    period.
    <br>
    &gt; <br>
    &gt; **Changelog:**
    <br>
    &gt; <br>
    &gt; * Added FutureLike interface methods: cancel(), isCompleted(),
    isCancelled()
    <br>
    &gt; * Renamed Coroutine::isFinished() to Coroutine::isCompleted()
    <br>
    &gt; * Clarified exit/die behavior: always triggers Graceful
    Shutdown mode
    <br>
    &gt; regardless of where called
    <br>
    &gt; * Added rationale for “Cancellable by design” policy: explains
    why
    <br>
    &gt; default cancellability reduces code complexity for read-heavy
    PHP
    <br>
    &gt; workloads
    <br>
    &gt; * RFC structure improvements: reorganized Cancellation section
    with
    <br>
    &gt; proper subsections hierarchy
    <br>
    &gt; * Moved “Coroutine lifetime” as subsection under Coroutine
    section
    <br>
    &gt; * Extended glossary with Awaitable, Suspension, Graceful
    Shutdown, and
    <br>
    &gt; Deadlock terms
    <br>
    &gt; * Introduced FutureLike interface with single-assignment
    semantics and
    <br>
    &gt; changed await() signature to accept FutureLike instead of
    Awaitable
    <br>
    &gt; for type safety
    <br>
    &gt; * Split RFC: Moved Scope and structured concurrency
    functionality to
    <br>
    &gt; separate Scope RFC. Base RFC now focuses on core async
    primitives
    <br>
    &gt; (coroutines, await, cancellation)
    <br>
    &gt; <br>
    &gt; I decided not to wait until Monday and made the changes today.
    If
    <br>
    &gt; anyone has read version 1.4 and has comments on it, they’re
    still
    <br>
    &gt; relevant.
    <br>
    &gt; <br>
    &gt; The Scope API has been moved to a separate RFC:
    <br>
    &gt; <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/true_async_scope">https://wiki.php.net/rfc/true_async_scope</a>
    <br>
    &gt; <br>
    &gt; ----
    <br>
    &gt; Best Regards, Ed<br>
    <br>
  </body>
</html>

--------------DMf0M0lXPeyoYIyx4OI8Gs6f--