Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126651
Date: Sat, 8 Mar 2025 15:00:14 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <9a2e81e8-3534-455b-879a-5a45c85b3ba7@gmail.com>
In-Reply-To: <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.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> <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> <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_10_4137397.1741442414931"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_10_4137397.1741442414931
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> As far as I can tell, the entire reason we are talking about this is because adding the event loop changes the behavior of existing code. So we cannot "just turn it on".
>
> I haven't seen an explanation of why this is the case, but that's how we got to this point. We need some way to "opt in" to turning on the event loop.

This also seems like a very bad idea: there is no reason for the language hide concurrency behind an INI or even worse a compilation flag.

Existing code may not all be free from races, but the choice should be up to the user, not the hoster or whoever provides the php distribution.

Enabling concurrency by default will allow gradual addition of fiber/threadsafety of codebases, as developers will know that concurrency is a (very easy to use) option, and will hopefully want to prepare their codebases for it, and after that happens, it will be even easier for users to use it.
(And actually, this is already the case, as fibers were added in 8.1, limiting the userland scheduler makes no sense now that (thankfully!!) the cat is out of the ba).

Regards,
Daniil Gentili.

------=_Part_10_4137397.1741442414931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
 <head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
 </head>
 <body>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; As far as I can tell, the entire reason we are talking about this is because adding the event loop changes the behavior of existing code. So we cannot "just turn it on".</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt;</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; I haven't seen an explanation of why this is the case, but that's how we got to this point. We need some way to "opt in" to turning on the event loop.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">This also seems like a very bad idea: there is no reason for the language hide concurrency behind an INI or even worse a compilation flag.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Existing code may not all be free from races, but the choice should be up to the user, not the hoster or whoever provides the php distribution.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Enabling concurrency by default will allow gradual addition of fiber/threadsafety of codebases, as developers will know that concurrency is a (very easy to use) option, and will hopefully want to prepare their codebases for it, and after that happens, it will be even easier for users to use it.</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">(And actually, this is already the case, as fibers were added in 8.1, limiting the userland scheduler makes no sense now that (thankfully!!) the cat is out of the ba).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Regards,</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Daniil Gentili.</span>
  <br>
 </body>
</html>
------=_Part_10_4137397.1741442414931--