Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126797
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------e0FXcx0ehvLG06ekQVsq1FM6"
Message-ID: <72bd5401-53a9-409f-ad45-687333401961@rwec.co.uk>
Date: Sun, 16 Mar 2025 23:01:01 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: internals@lists.php.net
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------e0FXcx0ehvLG06ekQVsq1FM6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 16/03/2025 09:24, Edmond Dantes wrote:
> Good day, everyone. I hope you're doing well.
>
> https://wiki.php.net/rfc/true_async
>
> Here is a new version of the RFC dedicated to asynchrony.


> I would like to once again thank everyone who participated in the 
> previous discussion. It was great!


Thank you for taking such a positive approach to the feedback, and 
continuing to really work hard on this!

I found this version of the RFC much more digestible than the last, and 
have some specific comments on various sections...


## Possible Syntax


 > In this RFC, you can see a potential new syntax for describing 
concurrency. This syntax is NOT a mandatory part of this RFC and may be 
adopted separately.

As I said in the previous thread, I disagree with this - control flow 
should use keywords, not functions. We don't expose a function 
Loop\while(callable $condition, callable $action): void

Having both just leads to confusing caveats, like:

 > Warning: The spawn function does not allow passing reference data as 
parameters. This limitation can be overcome using the spawn operator.


Specifically, I suggest keywords (and no function equivalents) for the 
following (names subject to bikeshedding):

- spawn
- spawn in $scope
  - await
- suspend
- defer

Some things proposed as methods can be easily composed from these 
keywords by the user:

// instead of $scope->awaitDirectChildren();
Async\await_all( $scope->getDirectChildren() );

// instead of $crucialCoroutine = $boundedScope->spawnAndBound( 
some_function() );
$crucialCoroutine = spawn in $boundedScope some_function();
$boundedScope->boundedBy($crucialCoroutine);


 > The spawn function can be replaced using the spawn operator, which 
has two forms ... executing a closure

This leads to an ambiguity / source of confusion:

function x(): int { return 42; }
spawn x(); // spawns x();
spawn function(): int { return 42; } // immediately evaluates the 
function() expression to a Closure, and then spawns it

$var = 42;
spawn $var; // presumably throws an error

$callable = function(): int { return 42; };
spawn $callable; // does this spawn the callable, or throw an error?

function foo(): callable { return bar(...); }
spawn foo(); // does this spawn foo(), or run foo() immediately and then 
spawn bar() ??


I suggest we instead allow "spawn" to be followed by a block, which 
implicitly creates and spawns a zero-argument Closure:

function x(): int { return 42; }
spawn x(); // spawns x();

$callable = function() { foo(); bar(); };
spawn $callable(); // spawns the Closure

spawn ( function() { foo(); bar(); } )(); // legal, but unlikely in 
practice; note the last (), to call the closure, not just define it

spawn { foo(); bar(); } // shorthand for the previous example

I'm not sure about variable capture - probably we would need a use() 
clause for consistency with function{}, and to avoid inventing a new 
capture algorithm:

$x = 42;
spawn use ($x) { do_something($x); do_something_else($x); }


## Lifetime Limitation


The RFC currently mentions "the Actor model" but doesn't actually 
explain what it is, or what "other languages" implement it. I imagine 
you wanted to avoid the explanation getting any longer, but maybe some 
links could be added to help people find examples of it?


## BoundedScope


This API needs a bit more thought I think:

* The name of "withTimeout" sounds like it will return a modified clone, 
and the description says it "creates" something, but the example shows 
it mutating an existing object
* What happens if boundedBy and/or spawnAndBound are called multiple 
times on the same BoundedScope? Is the lifetime the shortest of those 
provided? Or the longest? Or just the last one called?
* boundedBy should not accept "mixed", but a specific union (e.g. 
CancellationToken|Future|Coroutine) or interface (e.g. ScopeConstraint)


## Coroutine Scope Slots


The Async\Key class doesn't belong in the Async namespace or this RFC, 
but as a top-level feature of the language, in its own RFC.


In general, the "scope slots" API still feels over-engineered, and 
lacking a separation of concerns:

- I'm not convinced that supporting object keys is necessary; is it 
something userland libraries are widely implementing, or just personal 
taste?
- I don't understand the difference between find(), get(), findLocal(), 
and getLocal()
- Scope and Context seem like separate concerns, which should be 
composed not inherited
- automatic dereferencing of WeakReference seems an unnecessary piece of 
magic - unless I'm missing something, it just saves the user typing 
"->get()"

I haven't worked through all the use cases, but I think the key 
primitives are:

- Scope->getParent(): ?Scope
- Scope->getContext(): Context
- Coroutine->getContext(): Context
- Context->set(string $key, mixed $value): void
- Context->get(string $key): mixed

That allows for:

currentScope()->getContext()->get('scope_value');
currentScope()->getParent()->getContext()->get('inherited_value');
currentCoroutine()->getContext()->get('local_value');

A framework can build more complex inheritance relationships on top of 
that, e.g.

function get_from_request_scope(string $key): mixed {
     $scope = currentScope();
     while ( $scope !== null && ! 
$scope->getContext()->get('acme_framework::is_request_scope') ) {
         $scope = $scope->getParent();
     }
     return $scope?->get($key);
}



## Error Handling


 > If multiple points are awaiting, each will receive the exception.
 > ...
 > If the |Scope| has responsibility points, i.e., the construction 
|await $scope|, all responsibility points receive the exception.

Is the exception cloned into each of these coroutines, or are they all 
given exactly the same instance?

An exception being thrown in multiple places "simultaneously" is hard to 
visualise, and I wonder if it will lead to confusing situations.


 > $coroutine->cancel(new Async\CancellationException('Task was 
cancelled'));

This looks odd - why is the caller creating the exception? Can any 
exception be used there? I suggest:

$coroutine->cancel('some message'); // constructs an 
Async\CancellationException and throws it inside the coroutine


 > Warning: You should not attempt to suppress CancellationException 
exception, as it may cause application malfunctions.

This and other special behaviours suggest that this should inherit from 
Error rather than Exception, or possibly directly from Throwable



That's all for now. To reiterate: thank you so much for working on this, 
and I really like the shape it's beginning to take :)

-- 
Rowan Tommins
[IMSoP]

--------------e0FXcx0ehvLG06ekQVsq1FM6
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>
    <div class="moz-cite-prefix">On 16/03/2025 09:24, Edmond Dantes
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Good day, everyone. I hope you're doing well.
        <div><br>
        </div>
        <div>
          <div><a href="https://wiki.php.net/rfc/true_async"
              moz-do-not-send="true" class="moz-txt-link-freetext">https://wiki.php.net/rfc/true_async</a></div>
        </div>
        <div><br>
        </div>
        <div>Here is a new version of the RFC dedicated to asynchrony.<br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com">
      <div dir="ltr">
        <div>I would like to once again thank everyone who participated
          in the previous discussion. It was great!  <br>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Thank you for taking such a positive approach to the feedback,
      and continuing to really work hard on this!</p>
    <p>I found this version of the RFC much more digestible than the
      last, and have some specific comments on various sections...<br>
    </p>
    <p></p>
    <p><br>
    </p>
    <p>## Possible Syntax<br>
    </p>
    <p><br>
    </p>
    <p>&gt; In this RFC, you can see a potential new syntax for
      describing concurrency. This syntax is NOT a mandatory part of
      this RFC and may be adopted separately. <br>
    </p>
    <p>As I said in the previous thread, I disagree with this - control
      flow should use keywords, not functions. We don't expose a
      function Loop\while(callable $condition, callable $action): void<br>
    </p>
    <p>Having both just leads to confusing caveats, like:</p>
    <p>&gt; Warning: The spawn function does not allow passing reference
      data as parameters. This limitation can be overcome using the
      spawn operator. <br>
    </p>
    <p><br>
    </p>
    <p>Specifically, I suggest keywords (and no function equivalents)
      for the following (names subject to bikeshedding):<br>
    </p>
    <p>- spawn<br>
      - spawn in $scope<br>
       - await<br>
      - suspend<br>
      - defer</p>
    <p>Some things proposed as methods can be easily composed from these
      keywords by the user:<br>
    </p>
    <p>// instead of $scope-&gt;awaitDirectChildren();<br>
      Async\await_all( $scope-&gt;getDirectChildren() );<br>
    </p>
    <p>// instead of $crucialCoroutine =
      $boundedScope-&gt;spawnAndBound( some_function() );<br>
      $crucialCoroutine = spawn in $boundedScope some_function();<br>
      $boundedScope-&gt;boundedBy($crucialCoroutine); </p>
    <p></p>
    <p><br>
    </p>
    <p>&gt; The spawn function can be replaced using the spawn operator,
      which has two forms ... executing a closure<br>
    </p>
    <p>This leads to an ambiguity / source of confusion:<br>
    </p>
    <p>function x(): int { return 42; }<br>
      spawn x(); // spawns x();<br>
      spawn function(): int { return 42; } // immediately evaluates the
      function() expression to a Closure, and then spawns it</p>
    <p>$var = 42;<br>
      spawn $var; // presumably throws an error<br>
    </p>
    <p>$callable = function(): int { return 42; };<br>
      spawn $callable; // does this spawn the callable, or throw an
      error?<br>
      <br>
      function foo(): callable { return bar(...); }<br>
      spawn foo(); // does this spawn foo(), or run foo() immediately
      and then spawn bar() ??</p>
    <p><br>
    </p>
    <p>I suggest we instead allow "spawn" to be followed by a block,
      which implicitly creates and spawns a zero-argument Closure:<br>
    </p>
    <p>function x(): int { return 42; }<br>
      spawn x(); // spawns x();</p>
    <p>$callable = function() { foo(); bar(); };<br>
      spawn $callable(); // spawns the Closure<br>
    </p>
    <p>spawn ( function() { foo(); bar(); } )(); // legal, but unlikely
      in practice; note the last (), to call the closure, not just
      define it<br>
    </p>
    spawn { foo(); bar(); } // shorthand for the previous example<br>
    <p>I'm not sure about variable capture - probably we would need a
      use() clause for consistency with function{}, and to avoid
      inventing a new capture algorithm:<br>
    </p>
    <p>$x = 42;<br>
      spawn use ($x) { do_something($x); do_something_else($x); }<br>
    </p>
    <p><br>
    </p>
    <p>## Lifetime Limitation</p>
    <p><br>
    </p>
    <p>The RFC currently mentions "the Actor model" but doesn't actually
      explain what it is, or what "other languages" implement it. I
      imagine you wanted to avoid the explanation getting any longer,
      but maybe some links could be added to help people find examples
      of it?<br>
    </p>
    <br>
    <p>## BoundedScope</p>
    <p><br>
    </p>
    <p>This API needs a bit more thought I think:<br>
      <br>
      * The name of "withTimeout" sounds like it will return a modified
      clone, and the description says it "creates" something, but the
      example shows it mutating an existing object<br>
      * What happens if boundedBy and/or spawnAndBound are called
      multiple times on the same BoundedScope? Is the lifetime the
      shortest of those provided? Or the longest? Or just the last one
      called?<br>
      * boundedBy should not accept "mixed", but a specific union (e.g.
      CancellationToken|Future|Coroutine) or interface (e.g.
      ScopeConstraint)</p>
    <p><br>
    </p>
    <p>## Coroutine Scope Slots<br>
    </p>
    <p><br>
    </p>
    <p>The Async\Key class doesn't belong in the Async namespace or this
      RFC, but as a top-level feature of the language, in its own RFC.</p>
    <p><br>
    </p>
    <p>In general, the "scope slots" API still feels over-engineered,
      and lacking a separation of concerns:<br>
    </p>
    <p>- I'm not convinced that supporting object keys is necessary; is
      it something userland libraries are widely implementing, or just
      personal taste?<br>
      - I don't understand the difference between find(), get(),
      findLocal(), and getLocal()<br>
      - Scope and Context seem like separate concerns, which should be
      composed not inherited<br>
      - automatic dereferencing of WeakReference seems an unnecessary
      piece of magic - unless I'm missing something, it just saves the
      user typing "-&gt;get()"<br>
    </p>
    <p>I haven't worked through all the use cases, but I think the key
      primitives are:<br>
      <br>
      - Scope-&gt;getParent(): ?Scope<br>
      - Scope-&gt;getContext(): Context<br>
      - Coroutine-&gt;getContext(): Context<br>
      - Context-&gt;set(string $key, mixed $value): void<br>
      - Context-&gt;get(string $key): mixed</p>
    <p>That allows for:</p>
    <p>currentScope()-&gt;getContext()-&gt;get('scope_value');<br>
currentScope()-&gt;getParent()-&gt;getContext()-&gt;get('inherited_value');<br>
      currentCoroutine()-&gt;getContext()-&gt;get('local_value');</p>
    <p>A framework can build more complex inheritance relationships on
      top of that, e.g.<br>
    </p>
    <p>function get_from_request_scope(string $key): mixed {<br>
          $scope = currentScope();<br>
          while ( $scope !== null &amp;&amp; !
      $scope-&gt;getContext()-&gt;get('acme_framework::is_request_scope')
      ) { <br>
              $scope = $scope-&gt;getParent();<br>
          }<br>
          return $scope?-&gt;get($key);<br>
      }</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>## Error Handling</p>
    <p><br>
    </p>
    <p>&gt; If multiple points are awaiting, each will receive the
      exception.<br>
      &gt; ...<br>
      &gt; If the <code>Scope</code> has responsibility points, i.e.,
      the construction <code>await $scope</code>, all responsibility
      points receive the exception.</p>
    <p>Is the exception cloned into each of these coroutines, or are
      they all given exactly the same instance?<br>
    </p>
    <p>An exception being thrown in multiple places "simultaneously" is
      hard to visualise, and I wonder if it will lead to confusing
      situations.</p>
    <p><br>
    </p>
    <p>&gt; $coroutine-&gt;cancel(new Async\CancellationException('Task
      was cancelled'));<br>
    </p>
    <p>This looks odd - why is the caller creating the exception? Can
      any exception be used there? I suggest:<br>
    </p>
    <p>$coroutine-&gt;cancel('some message'); // constructs an
      Async\CancellationException and throws it inside the coroutine</p>
    <p><br>
    </p>
    <p>&gt; Warning: You should not attempt to suppress
      CancellationException exception, as it may cause application
      malfunctions. <br>
    </p>
    <p>This and other special behaviours suggest that this should
      inherit from Error rather than Exception, or possibly directly
      from Throwable</p>
    <p></p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>That's all for now. To reiterate: thank you so much for working
      on this, and I really like the shape it's beginning to take :)</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------e0FXcx0ehvLG06ekQVsq1FM6--