Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126592
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 05 Mar 2025 22:11:23 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
References: 
 <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com>
 <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com>
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Mar 5, 2025, at 3:10 PM, Edmond Dantes wrote:

>> No, just those functions/objects that necessarily involve running asy=
nc control commands.  Most wouldn't. =20
>> They would just silently context switch when they hit an IO operation=
 (which as noted above is transparency supported, which is what makes th=
is=20
>> work) and otherwise behave the same.=20
>
> So it's something more like Go or Python.
>
>>
>>  $val =3D async(function(AsyncContext $ctx) use ($stuff, $fn) {
>>  $result =3D [];
>>  foreach ($stuff as $item) {
>>   $result[] =3D $ctx->run($fn);
>>}
>>
>>  // We block/wait here until all subtasks are complete, then the asyn=
c() call returns this value.
>>  return $result;
>> });
>
> Do I understand correctly that at the point `$val =3D=20
> async(function(AsyncContext $ctx) use ($stuff, $fn)` execution stops=20
> until everything inside is completed?

Correct.  By the time $val is populated, all fibers/coroutines/tasks sta=
rted inside that block have completed and closed, guaranteed.  If an exc=
eption was thrown or something else went wrong, then by the time the exc=
eption escapes the asnc{} block, all fibers inside it are done and close=
d, guaranteed.  (If there's another async {} block further up the stack =
somewhere, there may still be other background fibers running, but anyth=
ing created inside that block is guaranteed done.)

> If so, let me introduce a second semantic option (for now, I'll remove=20
> the context and focus only on the function). =20
>
> ```php
> $url1 =3D 'https://domain1.com/';
> $url2 =3D 'https://domain2.com/';
>
> $url_handle =3D fn(string $url) =3D> file_get_contents($url);
>
> $res =3D Async\start(function() use ($url1, $url2, $url_handle) {
>     $res1 =3D Async\run($url_handle, $url1);
>     $res2 =3D Async\run($url_handle, $url2);
>
>     Async\run(fn() =3D> sleep(5));
>
>     // some logic here
>
>     return $merged_result;
> });
> ```
>
> What's Happening Here:
>
>  1. After calling `$res =3D Async\start()`, the code waits until the=20
> entire block completes.
>  2. Inside `Async\start`, the code waits for all nested coroutines to=20
> finish.
>  3. If a coroutine has other nested coroutines, the same rule applies.
> Rules Inside an Asynchronous Block:
>
>  1. I/O functions do not block coroutines within the block.
>  2. Creating a new `Fiber` is not allowed =E2=80=94 an exception will =
be=20
> thrown: you cannot use `Fiber`.
>  3. Unhandled exceptions will be thrown at the point of `$res =3D=20
> Async\start()`.
> Coroutine Cancellation Rules:
>
> Canceling a coroutine cancels it and all its child coroutines (this=20
> cannot be bypassed unless the coroutine is created in a different=20
> context).
>
> How does this option sound to you?

We can quibble on the details and spelling, but I think the overall logi=
c is sound.  One key question, if we disallow explicitly creating Fibers=
 inside an async block, can a Fiber be created outside of it and not blo=
ck async, or would that also be excluded?  Viz, this is illegal:

async {
  $f =3D new Fiber(some_func(...));
}

But would this also be illegal?

$f =3D new Fiber(some_func(...));
$f->start();

async {
  do_stuff();
}

> Essentially, this is Kotlin, but it should also resemble Python.=20
> However, unlike Kotlin, there are no special language constructs=20
> here=E2=80=94code blocks naturally serve that role. Of course, syntact=
ic sugar=20
> can be added later for better readability. =20

My brief foray into Kotlin in a previous job didn't get as far as corout=
ines, so I will take your word from it.  From a very cursory glance at t=
he documentation, I think runBlocking {} is approximately what I am desc=
ribing, yes.  The various other block types I don't know are necessary.

> And if you like this, I have good news: there are no implementation=20
> issues at this level.
>
> In terms of semantic elegance, the only thing that bothers me is that=20
> `return` behavior is slightly altered =E2=80=94 meaning the actual "re=
turn"=20
> won=E2=80=99t happen until all child functions complete. This isn=E2=80=
=99t very good,=20
> and Kotlin=E2=80=99s style would fit better here.

I'm not sure I follow.  The main guarantee we want is that "once you pas=
s this }, all fibers/coroutines have ended, count on it."  Do you mean s=
omething like this?

async $ctx {
  $ctx->run(foo(...));
  $ctx->run(bar(...));

  // This return statement blocks until foo() and bar() complete.
  return "all done";
}

That doesn't seem any weirder than return and finally{} blocks. :-)  (No=
te that we can and should consider if async {} makes sense to have its o=
wn catch and finally blocks built in.)

> But on the other hand =E2=80=94 can we live with this?

This seems far closer to something I'd support than the current RFC, yes.

>> I cannot speak to JS Symbols as I haven't used them. =20
>> I am just vhemently opposed to globals, no matter how many layers the=
y're wrapped in. :-)  Most uses could be replaced by proper DI or partia=
l application.
>
> You won=E2=80=99t be able to use DI because you have only *one service=20
> (instance of class)* for the entire application, not a separate servic=
e=20
> for each coroutine. This service is shared across the application and=20
> can be called from any coroutine. As a result, the service needs memor=
y=20
> slots to store or retrieve data. DI is a mechanism used once during=20
> service initialization, not every time a method is called.

Not true.  DI doesn't imply singleton objects.  Most good DI *containers=
* default to singleton objects, as they should, but for example Laravel'=
s container does not.  You have to opt-in to singleton behavior.  (I thi=
nk that's a terrible design, but it's still DI.)

DI just means "a scope gets the stuff it needs given to it, it never ask=
s for it."  How that stuff is passed in is, deliberately, undefined.  A =
DI container is but one way.

In Crell/Serde, I actually use "runner objects" a lot.  I have an exampl=
e here:

https://presentations.garfieldtech.com/slides-serialization/longhornphp2=
023/#/7/4/3

That is still dependency injection, because ThingRunner is still taking =
all of its dependencies via the constructor.  And being readonly, it's s=
till immutable-friendly.

That's the sort of thing I'm thinking of here for the async context.  To=
 spitball again:

class ClientManager {
  public function __construct(string $base) {}

  public function client(AsyncContext $ctx) {
    return new HttpClient($this->base, $ctx);
  }
}

class HttpClient {
  public function __construct(private string $base, private AsyncContext=
 $ctx) {}

  public function get(string $path) {
    $this->ctx->defer(fn() =3D> print "Read $path\n");
    return $this->ctx->run(fn() =3D> file_get_contents($this->base . $pa=
th));
  }
}

$manager =3D $container->get(ClientManager::class);

async $ctx {
  $client =3D $manager->client($ctx);
  $client->get('/foo');
  $client->get('/bar');
}=20
// We don't get here until all file_get_contents() calls are complete.
// The deferred functions all get called right here.

// There is no no async happening anymore.
print "Done";=20

I'm pretty sure the return values are all messed up there, but hopefully=
 you get the idea.  Now HttpClient has a fully injected context that con=
trols what async scope it's working in.  The same class can be used in a=
 bunch of different async blocks, each with their own context.  You can =
even mock AsyncContext for testing purposes just like any other construc=
tor argument.  And not a global function or variable in sight! :-)

--Larry Garfield