Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126684
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 09 Mar 2025 23:43:51 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <2b7dfacf-fd9f-4692-8b92-b2f22591d32a@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8Dzin0sYioWFCJHOfaLASLwuSggijV2=2qQA5tO4a0itA@mail.gmail.com>
References: <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
 <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com>
 <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com>
 <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
 <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
 <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com>
 <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com>
 <77DC5F50-531D-49E8-8BE2-504A19CB5FFD@rwec.co.uk>
 <676e36e4-0b84-4d8c-b3db-2998831cd79d@gmail.com>
 <510B8EF1-9D07-41A8-9EA0-7D99CF7BFC91@rwec.co.uk>
 <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
 <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com>
 <CAMW7n8DTVPkA0qk30TCf1+L3Rmooyt5eEMco+=ds_TX3fEXn-Q@mail.gmail.com>
 <4871b2e4-353e-424f-92b9-7e2bb753bafa@gmail.com>
 <CAMW7n8Dzin0sYioWFCJHOfaLASLwuSggijV2=2qQA5tO4a0itA@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 Sun, Mar 9, 2025, at 11:56 AM, Edmond Dantes wrote:

> *Let me summarize the current state for today:*
>
>  1. I am abandoning `startScheduler` and the idea of preserving=20
> backward compatibility with `await_all` or anything else in that=20
> category. The scheduler will be initialized implicitly, and this does=20
> not concern user-land. Consequently, the `spawn function()` code will=20
> work everywhere and always.
>
>  2. I will not base the implementation on `Fiber` (perhaps only on the=20
> low-level part). Instead of `Fiber`, there will be a separate class.=20
> There will be no changes to `Fiber` at all. This decision follows the=20
> principle of Win32 COM/DCOM: old interfaces should never be changed. I=
f=20
> an old interface needs modification, it should be given a new name.=20
> This should have been done from the start.
>
>  3. I am abandoning low-level objects in PHP-land (FiberHandle,=20
> SocketHandle etc). Over time, no one has voted for them, which means=20
> they are unnecessary. There might be a low-level interface for=20
> compatibility with Revolt.
>
>  4.   It might be worth restricting microtasks in PHP-land and keeping=20
> them only for C code. This would simplify the interface, but we need t=
o=20
> ensure that it doesn=E2=80=99t cause any issues. =20
>
>
> The remaining question on the agenda: deciding which model to choose =E2=
=80=94=20
> *parent-child* or the *Go-style model*.

As noted, I am in broad agreement with the previously linked article on =
"playpens" (even if I hate that name), that the "go style model" is too =
analogous to goto statements.

Basically, this is asking "so do we use gotos or for loops?"  For which =
the answer is, I hope obviously, for loops.

Offering both, frankly, undermines the whole point of having structured,=
 predictable concurrency.  The entire goal of that is to be able to know=
 if there's some stray fiber running off in the background somewhere sti=
ll doing who knows what, manipulating shared data, keeping references to=
 objects, and other nefarious things.  With a nursery, you don't have th=
at problem... *but only if you remove goto*.  A language with both a for=
 loop and an arbitrary goto statement gets basically no systemic benefit=
 from having the for loop, because neither developers nor compilers get =
any guarantees of what will or won't happen.

Especially when, as demonstrated, the "this can run in the background an=
d I don't care about the result" use case can be solved more elegantly w=
ith nested blocks and channels, and in a way that, in practice, would pr=
obably get subsumed into DI Containers eventually so most devs don't hav=
e to worry about it.

Of interesting note along similar lines would be Rust, and... PHP.=20

Rust's whole thing is memory safety.  The language simply will not let y=
ou write memory-unsafe code, even if it means the code is a bit more ver=
bose as a result.  In exchange for the borrow checker, you get enough me=
mory guarantees to write extremely safe parallel code.  However, the des=
igners acknowledge that occasionally you do need to turn off the checker=
 and do something manually... in very edge-y cases in very small blocks =
set off with the keyword "unsafe".  Viz, "I know what I'm doing is stupi=
d, but trust me."  The discouragement of doing so is built into the lang=
uage, and tooling, and culture.

PHP... has a goto operator.  It was added late, kind of as a joke, but i=
t's there.  However, it is not a full goto.  It can only jump within the=
 current function, and only "up" control structures.  It's basically a n=
amed break.  While it only rarely has value, it's not al that harmful un=
less you do something really dumb with it.  And then it's only harmful w=
ithin the scope of the function that uses it.  And, very very rarely, th=
ere's some micro-optimization to be had.  (cf, this classic: https://git=
hub.com/igorw/retry/issues/3).  But PHP has survived quite well for 30 y=
ears without an arbitrary goto statement.

So if we start from a playpen-like, structured concurrency assumption, w=
hich (as demonstrated) gives us much more robust code that is easier to =
follow and still covers nearly all use cases, there's two questions to a=
nswer:

1. Is there still a need for an "unsafe {}" block or in-function goto eq=
uivalent?
2. If so, what would that look like?

I am not convinced of 1 yet, honestly.  But if it really is needed, we s=
hould be targeting the least-uncontrolled option possible to allow for t=
hose edge cases.  A quick-n-easy "I'mma violate the structured concurren=
cy guarantees, k?" undermines the entire purpose of structured concurren=
cy.

> During our discussion, everything seems to be converging on the idea=20
> that the changes introduced by the RFC into `Fiber` would be better=20
> moved to a separate class. This would reduce confusion between the old=20
> and new solutions. That way, developers wouldn't wonder why `Fiber` an=
d=20
> coroutines behave differently=E2=80=94they are simply different classe=
s.
> The new *Coroutine* class could have a different interface with new=20
> logic. This sounds like an excellent solution.
>
> The interface could look like this:
>
>  =E2=80=A2 *`suspend`* (or another clear name) =E2=80=93 a method that=
 explicitly hands=20
> over execution to the *Scheduler*.
>  =E2=80=A2 *`defer`* =E2=80=93 a handler that is called when the corou=
tine completes.
>  =E2=80=A2 *`cancel`* =E2=80=93 a method to cancel the coroutine.
>  =E2=80=A2 *`context`* =E2=80=93 a property that stores the execution =
context.
>  =E2=80=A2 *`parent`* (public property or `getParent()` method) =E2=80=
=93 returns the=20
> parent coroutine.
> (*Just an example for now.*)
>
> The *Scheduler* would be activated automatically when a coroutine is=20
> created. If the `index.php` script reaches the end, the interpreter=20
> would wait for the *Scheduler* to finish its work under the hood.
>
> Do you like this approach?

That API is essentially what I was calling "AsyncContext" before.  I am =
flexible on the name, as long as it is descriptive and gives the user th=
e right mental model. :-)  (I'm not sure if Coroutine would be the right=
 name either, since in what I was describing it's the spawn command that=
 starts a coroutine; the overall async scope is the container for severa=
l coroutines.)

But perhaps that is a sufficient "escape hatch"?  Spitballing again:

async $nursery { // Formerly AsyncContext
  // Runs at the end of this nursery scope
  $nursery->defer($fn);

  // This creates and starts a coroutine, in this scope.
  $future =3D $nursery->spawn($fn);

  // A short-hand for "spawn this coroutine, in whatever the nearest asy=
nc nursery scope is.
  // aka, an alias for the above line, but doesn't require passing $nurs=
ery around.
  $future spawn $fn;

  // If you want.
  $future->cancel();

  // See below.
  $nursery->spawn(stuff(...));
} // This blocks until escape() finishes, too, because it was bound to t=
his scope.

function stuff() {
  async $inner {
      // This is bound to the $inner scope; $inner cannot end
      // until this is complete.  This is by design.
      spawn $inner;

      // This spawns a new coroutine on the parent scope, if any.
      // If there isn't one, $inner->parent is null so it falls back
      // to the current scope.
      // One could technically climb the entire tree to the top-most
      // scope and spawn a coroutine there.  It would be a bit annoying =
to do,
      // but, as noted, that's a good thing, because you shouldn't be do=
ing that 99.9% of the time!
      // Channels are better 99.9% of the time.
      ($inner->parent ?? $inner)->spawn(escape(...));
    }
}

I'm not sure I fully like the above.  I don't know if it makes the guara=
ntees too weak still.  But it does offer a limited, partial escape hatch=
, so may be an acceptable compromise.

It would be valuable to take this idea (or whatever we end up with) to e=
xperts in other languages with better async models than JS, and maybe a =
few academics, to let them poke obvious-to-them holes in it.

Edmund, does that make any sense to you?

--Larry Garfield