Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126605
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 06 Mar 2025 13:07:34 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@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>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
 <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@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 Thu, Mar 6, 2025, at 2:52 AM, Edmond Dantes wrote:
>>  One key question, if we disallow explicitly creating Fibers inside a=
n async block,=20
>> can a Fiber be created outside of it and not block async, or would th=
at also be excluded?  Viz, this is illegal:
>>
> Creating a `Fiber` outside of an asynchronous block is allowed; this=20
> ensures backward compatibility.
> According to the logic integrity rule, an asynchronous block cannot be=20
> created inside a Fiber. This is a correct statement.
>
> However, if the asynchronous block blocks execution, then it does not=20
> matter whether a Fiber was created or not, because it will not be=20
> possible to switch it in any way.
> So, the answer to your question is: yes, such code is legal, but the=20
> Fiber will not be usable for switching.
>
> In other words, Fiber and an asynchronous block are mutually exclusive=
.=20
> Only one of them can be used at a time: either Fiber + Revolt or an=20
> asynchronous block.
>
> Of course, this is not an elegant solution, as it adds one more rule t=
o=20
> the language, making it more complex. However, from a legacy=20
> perspective, it seems like a minimal scar.
>
> (to All: Please leave your opinion if you are reading this )

This seems like a reasonable approach to me, given the current state.  A=
t any give time, you can have "manual" or "automatic" handling in use, b=
ut one has to completely finish before you can start using the other.  W=
hether we should remove the "manual" access in the future becomes a ques=
tion for the future.

>>  // This return statement blocks until foo() and bar() complete.
>
> Yes, *that's correct*. That's exactly what I mean.
>
> Of course, under the hood, `return` will execute immediately if the=20
> coroutine is not waiting for anything. However, the Scheduler will=20
> store its result and pause it until the child coroutines finish their=20
> work.
>
> In essence, this follows the parent-child coroutine pattern, where the=
y=20
> are always linked. The downside is that it requires more code inside=20
> the implementation, and some people might accuse us of a paternalistic=20
> approach. :)

See, what you call "paternalistic" I say is "basic good usability."  Aff=
ordances are part of the design of everything.  Good design means making=
 doing the right thing easy and the wrong thing hard, preferably impossi=
ble.  (Eg, why 120v and 220v outlets have incompatible plugs, to use the=
 classic example.)  I am a strong support of correct by construction / m=
ake invalid states unrepresentable / type-driven development, or whateve=
r it's called this week. =20

And history has demonstrated that humans simply cannot be trusted to man=
ually handle synchronization safely, just like they cannot be trusted to=
 manually handle memory safely. :-)  (That's why green threads et al exi=
st.)

>>  That is still dependency injection, because ThingRunner is still tak=
ing all of its dependencies via the constructor.  And being readonly, it=
's still immutable-friendly.
>>=20
>
> Yeah, so basically, you're creating the service again and again for=20
> each coroutine if the coroutine needs to use it. This is a good=20
> solution in the context of multitasking, but it loses in terms of=20
> performance and memory, as well as complexity and code size, because i=
t=20
> requires more factory classes.

Not necessarily.  It depends on what all you're doing when creating thos=
e objects.  It can be quite fast.  Plus, if you want a simpler approach,=
 just pass the context directly:

async $ctx {
  $ctx->run($httpClient->runAsync($ctx, $url));
}

It's just a parameter to pass.  How you pass it is up to you.

It is literally the same argument for "pass the DB connection into the c=
onstructor, don't call a static method to get it" or "pass in the curren=
t user object to the method, don't call a global function to get it."  T=
hese are decades-old discussions with known solved problems, which all b=
oil down to "pass things explicitly."

To quote someone on FP: "The benefit of functional programming is it mak=
es data flow explicit.  The downside is it sometimes painfully explicit."

I am far happier with explicit that is occasionally annoyingly so, and b=
uilding tools and syntax to reduce that annoyance, than having implicit =
data just floating around in the ether around me and praying it's what I=
 expect it to be.

> The main advantage of *LongRunning* is initializing once and using it=20
> multiple times. On the other hand, this approach explicitly manages=20
> memory, ensuring that all objects are created within the coroutine's=20
> context rather than in the global context.

As above, in simpler cases you can just make the context a boring old fu=
nction parameter, in which case the perf overhead is unmesurable.

> Ah, now I see how much you dislike global state! :)

It is the root of all evil.

> However, in a scenario where a web server handles many similar=20
> requests, "global state" might not necessarily win in terms of speed=20
> but rather due to the simplicity of implementation and the overall=20
> maintenance cost of the code. (I know that in programming, there is an=20
> entire camp of immutability advocates who preach that their approach i=
s=20
> the key remedy for errors.)
>
> I would support both paradigms, especially since it doesn=E2=80=99t co=
st much.

Depends on the cost you mean.  If you have "system with strong guarantee=
s" and "system with no guarantees" interacting, then you have a system w=
ith no guarantees.  Plus the cost of devs having to think about two diff=
erent APIs, one of which is unit testable and one of which isn't, or at =
least not easily.

Do you have a concrete example of where the inconvenience of explicit co=
ntext is sufficiently high to warrant an implicit global and all the imp=
acts that has?

--Larry Garfield