Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126664
Date: Sat, 08 Mar 2025 23:12:24 +0000
To: internals@lists.php.net, Daniil Gentili <daniil.gentili@gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
User-Agent: K-9 Mail for Android
In-Reply-To: <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
References: <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.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> <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>
Message-ID: <CEF1AF2A-51A7-4CC9-90CD-31BE0512B476@php.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: derick@php.net (Derick Rethans)

Hi,=20

To see to be posting a reply to nearly every other email on this thread=2E=
 I'd recommend you have another read through our mailing list rules: <https=
://github=2Ecom/php/php-src/blob/master/docs/mailinglist-rules=2Emd>

cheers=20
Derick=20

On 8 March 2025 22:28:58 GMT, Daniil Gentili <daniil=2Egentili@gmail=2Ecom=
> wrote:
>>> To make an analogy, it's like saying PHP should have an io {} block, t=
hat makes sure all file resources opened within (even internally, 10 stack =
levels deep into 3 libraries, whose instances are all used after the io {} =
block) are closed when exiting=2E
>>
>> Traditional PHP offers exactly this: the SAPI lifecycle tracks all file=
 handles opened within a request, and closes them cleanly before reusing th=
e thread or process for another request=2E Essentially what I'm proposing i=
s a way to implement the same isolation in userland, by marking a checkpoin=
t in the code=2E
>
>Exposing this in userland offers an extremely dangerous footgun that will=
 severely limit concurrency=2E
>
>> As I've said repeatedly, it doesn't necessarily need to be a mandatory =
restriction, it can be a feature to help users write code without having to=
 worry about *accidentally* leaving a background fiber running=2E
>
>Even its use is optional, its presence in the language could lead library=
 developers to reduce concurrency in order to allow calls from async blocks=
, (i=2Ee=2E don't spawn any background fiber in a method call because it mi=
ght be called from an async {} block) which is what I meant by crippling as=
ync PHP=2E
>
>Libraries can and should handle cleanup of running fibers by themselves, =
on their own terms, without externally imposed limitations=2E
>
>It makes absolutely no sense, especially for a SAPI, to force all backgro=
und fibers to stop after a request is finished=2E
>
>It would force users to stop and restart all running fibers on each reque=
st, which is precisely the main argument for the use of worker mode: reduci=
ng overhead by keeping caches primed, sockets open and background loops run=
ning=2E
>
>PHP itself explicitly offers an escape hatch around the "io {} block" of =
current SAPIs, in the form of persistent resources (and again, this is all =
for performance reasons)=2E
>
>Even ignoring performance considerations, as I said many times, offering =
this tool to userland is a major footgun that will either backfire spectacu=
larly (breaking existing and new async libraries by endlessly awaiting upon=
 background fibers when exiting an async {} block haphazardly used by a new=
bie, or even worse force library developers to reduce concurrency, killing =
async PHP just because users can use async {} blocks), or simply not get us=
ed at all (because the main SAPI usecase listed explicitly does NOT need pu=
rity)=2E
>
>Regards,
>Daniil Gentili=2E