Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126672 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 3FA461A00BC for ; Sun, 9 Mar 2025 09:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1741512720; bh=n5jIyaZCFXm1rHTSNnZNPiwWzLf4hrcszpHF/kHMSq8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=SRCQ3AztWpH1ln3qRPJOqmziDm3Bp45a+NJm1lqm65kiX+jMOGyc4FpybjCDfbsGw Ky7xBYKXpqGf0dQDwijH4uNbpcLvFVwAxIGXtodponV46dInmBBB/8kurg0onPac1L 01v/ZGXh+oPD5R0pA1nuw9/Ajp/72Ja6O35hV7j6BI07P8YzS5qobnRRM9f4cQHSpV AreFAWH+EdojdXeURo+ohLFECJud3iWk6otkut/+68kCc6xW2tW0FcR3FIKLOlBKBi MZz86Xq0u3x5S19qrMeylQQpYZSMtYG8dKh4yN027mM8GMyXX7As0iSSj0U/wepkQ+ I2uhwhHqUdVjg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5A60E180037 for ; Sun, 9 Mar 2025 09:31:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 9 Mar 2025 09:31:58 +0000 (UTC) Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5dccaaca646so6538350a12.0 for ; Sun, 09 Mar 2025 01:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741512872; x=1742117672; darn=lists.php.net; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=w7aCbZGrVVskAmx9bH9l23lAUfh1n6k1YwulGrVOf9U=; b=CMFwpQb1pFyF1yMnMeDYD1DRyLeALtl1sRSlA68QOtUSJhlmwaUPE2p5jd0I9o5/xH 8zHrs8gIbV1rKZ0Tm7lMJytElodIo/b1Rhd6xml+NBukOW/Cwupd9fbv8T1pu+1j2MCP /Rsv3q8NGFt/KH8pyeF9LACj/C6E68FmYpCoLez05bz6n4p3xvt4SlWij6Dz7rDfcbEU Ij4IP42XftsfYEdUJNYZoAw2VxU6y9ru0sLwSTXJilfEFrROg4BORmCKi+YbA+bz8GUV d9hjkhfa4ENd2SIKeEBsSPP1bUtIIG0vsU6dqFbflNaiH1vGVNdlrLRK0hq8Yk/sR310 gbTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741512872; x=1742117672; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=w7aCbZGrVVskAmx9bH9l23lAUfh1n6k1YwulGrVOf9U=; b=AaVGHzIEYGl95JyESG+lYLQnmfTN1GD5kg4uXMPuka3ccYAeFmc1LAetNqvYzUo+9R SGrKwVld733q/g4rGqiIUThFW8d2uRc05saynaT802jcYAVdlm7SlAL04CV+AMwt0Khe cYIJi2rBvrcmdqcnLj9o+E7bVJdNiAnyiN8pjZBZMXlMh7XFndY/yXAclmtAz//l0CnM HdEvzOwSpgbxyWlRZs2FgnrhCnU4PWZTBZFpAPK/h0ZRiKf+8jmgKvBBvQfUibYuU+au woRQMdZJcqS3wvw4cei5OsT/s9nPPtWro3HkBm8dn65sCH2jYrgl5gZ7BbCFord3O6b8 go5w== X-Gm-Message-State: AOJu0YzzWsUY5rUzLJ5GPataaNxzJox3YeSK2K3kdGuSxwTIkOHjpf/p uqWgvb1pyTyj3wPapj9FOseg3G/o0M3rDT6t9v+CaAhDpiYXYHvsXzokMA== X-Gm-Gg: ASbGncu1TLQbs/9yM5sUa4ZgcoD/bwP+/GPIa3kBnyBwDhqAfCH8imMvFAgyya7neu6 tFd4RGE4QIQ/LVeV60IUjMbeXyjuJRtmVAbKC5wO7HX/qNixmdb9hWhSGwtUPwyfMwoGJe3rAP/ IlScnBh+EOoi812s2ZhjbcpNnnPm+ru9Yhqb08jkvDXukQ3oD9YEeyluv3QkWkj6culQ/hBWH5f wmMyRJ3LkZ8gCuZNedaxx4Z0VmX2L0DOL32VMCbrMm/u68O/u96Tf8djBsBPEkze/SQy6XoZRzg cn0MtPTMbSwU3x2MAK0CYGptFTGoCndHy3W8mUw/Z7IefsVh7Ccr74U5i/EQWD43YmgAKe4vJ+W u8lmiOVdUgIxaVcujoL4mU5q2QsjR X-Google-Smtp-Source: AGHT+IFQ7mUIwRNjosqzcrijmryyv8JkVwj9aChjdY9qQbJf9luQpy9yXQZ7MV9KGlwke/xfCaGbOQ== X-Received: by 2002:aa7:d60e:0:b0:5e0:8a27:cd36 with SMTP id 4fb4d7f45d1cf-5e614f9e2e1mr5002660a12.8.1741512871714; Sun, 09 Mar 2025 01:34:31 -0800 (PST) Received: from ?IPv6:::1? (luna-749a6f85f554075d0000f.net.as198747.daniil.it. [2a0e:97c0:38f:0:d570:455f:58f6:a947]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e5c733f8b5sm5071354a12.12.2025.03.09.01.34.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Mar 2025 01:34:30 -0800 (PST) Date: Sun, 9 Mar 2025 10:34:27 +0100 (GMT+01:00) To: internals@lists.php.net Message-ID: <4871b2e4-353e-424f-92b9-7e2bb753bafa@gmail.com> In-Reply-To: References: <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk> <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> <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> <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com> Subject: Re: [PHP-DEV] PHP True Async RFC Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17_203618216.1741512867684" X-Correlation-ID: <4871b2e4-353e-424f-92b9-7e2bb753bafa@gmail.com> From: daniil.gentili@gmail.com (Daniil Gentili) ------=_Part_17_203618216.1741512867684 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >>=C2=A0The wait_all block is EXPLICITLY DESIGNED to meddle with the intern= als of async libraries, >> > > How exactly does it interfere with the implementation of asynchronous lib= raries?=C2=A0 > Especially considering that these libraries operate at the User-land leve= l? It=E2=80=99s a contract. No more. No less. When you have a construct that is forcing all code within it to to terminat= e all running fibers. If any library invoked within a wait_all block suddenly decides to spawn a = long-running fiber that is not stopped when exiting the block, but for exam= ple later, when the library itself decides to, the wait_all block will not = exit, essentially forcing the library user or developer to mess with the in= ternal and forcefully terminate the background fiber. The choice should never be up to the caller, and the presence of the wait_a= ll block gives any caller the option to break the internal logic of librari= es. I can give you several examples where such logic is used in Amphp libraries= , and it will break if they are invoked within an async block. >>=C2=A0 Libraries can full well handle cleanup of fibers in __destruct by = themselves, without a wait_all block forcing them to reduce concurrency whe= never the caller pleases. >> > Fiber is a *final* class, so there can be no destructors here. Even if yo= u create a "Coroutine" class and allow defining a destructor, the result wi= ll be overly verbose code. I and many other developers have tested this. You misunderstand: this is about storing the FiberHandles of spawned fibers= and awaiting them in the __destruct of an object (the same object that spa= wned them in a method), in order to make sure all spawned fibers are awaite= d and all unhandled exceptions are handled somewhere (in absence of an even= t loop error handler). Also see my discussion about ignoring referenced futures: https://externals= .io/message/126537#126661 > >> >>=C2=A0 It is, imo, a MAJOR FOOTGUN, and should not be even considered for= implementation. >>=C2=A0 =C2=A0 > > Why exactly is this a FOOTGUN? > > * Does this block lead to new violations of language integrity? > * Does this block increase the likelihood of errors? 1) Yes, because it gives users tools to mess with the internal behavior of = userland libraries 2) Yes, because (especially given how it's named) accidental usage will bre= ak existing and new async libraries by endlessly awaiting upon background f= ibers when exiting an async {} block haphazardly used by a newbie when call= ing most async libraries, or even worse force library developers to reduce = concurrency, killing async PHP just because users can use async {} blocks. > A FOOTGUN is something that significantly breaks the language and pushes = developers toward writing bad code. This is a rather serious flaw. Indeed, this is precisely the case. As the maintainer of Psalm, among others, I fully understand the benefits o= f purity and immutability: however, this keyword is a toy exercise in purit= y, with no real usecases (all real usecases being already covered by awaitA= ll), which cannot work in the real world in current codebases and will brea= k real-world applications if used, with consequences on the ecosystem. I don't know what else to say on the topic, I feel like I've made myself cl= ear on the matter: if you still feel like it's a good idea and it should be= added to the RFC as a separate poll, I can only hope that the majority wil= l see the danger of adding such a useless keyword and vote against on that = specific matter. Regards, Daniil Gentili. ------=_Part_17_203618216.1741512867684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>&n= bsp;The wait_all block is EXPLICITLY DESIGNED to meddle with the internals = of async libraries,
>>
>
> How e= xactly does it interfere with the implementation of asynchronous libraries?=  
> Espec= ially considering that these libraries operate at the User-land level? It= =E2=80=99s a contract. No more. No less.


When you h= ave a construct that is forcing all code within it to to terminate all runn= ing fibers.

If any lib= rary invoked within a wait_all block suddenly decides to spawn a long-runni= ng fiber that is not stopped when exiting the block, but for example later,= when the library itself decides to, the wait_all block will not exit, esse= ntially forcing the library user or developer to mess with the internal and= forcefully terminate the background fiber.

The choice= should never be up to the caller, and the presence of the wait_all block g= ives any caller the option to break the internal logic of libraries.

I can give= you several examples where such logic is used in Amphp libraries, and it w= ill break if they are invoked within an async block.

>>&n= bsp; Libraries can full well handle cleanup of fibers in __destruct by them= selves, without a wait_all block forcing them to reduce concurrency wheneve= r the caller pleases.
>>
> Fiber= is a *final* class, so there can be no destructors here. Even if you creat= e a "Coroutine" class and allow defining a destructor, the result will be o= verly verbose code. I and many other developers have tested this.

You misund= erstand: this is about storing the FiberHandles of spawned fibers and await= ing them in the __destruct of an object (the same object that spawned them = in a method), in order to make sure all spawned fibers are awaited and all = unhandled exceptions are handled somewhere (in absence of an event loop err= or handler).
Also see m= y discussion about ignoring referenced futures: https://externals.io/messag= e/126537#126661

>
>>
>>&n= bsp; It is, imo, a MAJOR FOOTGUN, and should not be even considered for imp= lementation.
>>&n= bsp;  
>
> Why e= xactly is this a FOOTGUN?
>
> * Doe= s this block lead to new violations of language integrity?
> * Doe= s this block increase the likelihood of errors?

1) Yes, be= cause it gives users tools to mess with the internal behavior of userland l= ibraries
2) Yes, be= cause (especially given how it's named) accidental usage will break existin= g and new async libraries by endlessly awaiting upon background fibers when= exiting an async {} block haphazardly used by a newbie when calling most a= sync libraries, or even worse force library developers to reduce concurrenc= y, killing async PHP just because users can use async {} blocks.


> A FOO= TGUN is something that significantly breaks the language and pushes develop= ers toward writing bad code. This is a rather serious flaw.

Indeed, th= is is precisely the case.

As the mai= ntainer of Psalm, among others, I fully understand the benefits of purity a= nd immutability: however, this keyword is a toy exercise in purity, with no= real usecases (all real usecases being already covered by awaitAll), which= cannot work in the real world in current codebases and will break real-wor= ld applications if used, with consequences on the ecosystem.

I don't kn= ow what else to say on the topic, I feel like I've made myself clear on the= matter: if you still feel like it's a good idea and it should be added to = the RFC as a separate poll, I can only hope that the majority will see the = danger of adding such a useless keyword and vote against on that specific m= atter.

Regards,
Daniil Gen= tili.
------=_Part_17_203618216.1741512867684--