Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129383
Content-Type: multipart/alternative;
 boundary="------------YIXyEIZ5LWIn7fiGhFHcUghb"
Message-ID:
 <AM8P250MB01703D8EA7280D024B0623DDE2D2A@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Sat, 22 Nov 2025 05:50:08 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Jakub Zelenka <bukka@php.net>, Edmond Dantes <edmond.ht@gmail.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <C58ADF49-6E21-4E25-8859-2A0769829E38@php.net>
 <e8625214-1c6f-40b8-b24f-e592e6f92012@beccati.com>
 <CAMW7n8Dy3=QyCrG4BMwVXWAipgOr2Vyhy_jbLVTYeq2Jc5v15g@mail.gmail.com>
 <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk>
 <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
 <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk>
 <CAMW7n8CLZ7yFhUhh89wx7L+YwQ25LA7HZoGWUFB3R76KgXko2w@mail.gmail.com>
 <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|DU2P250MB0319:EE_
X-MS-Office365-Filtering-Correlation-Id: d7585d5f-6ea9-4f30-f3f6-08de29829eb3
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|12121999013|8060799015|15080799012|23021999003|461199028|19110799012|51005399006|5072599009|40105399003|3412199025|440099028|26104999006;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WTR3MnpneHRyZHFhZlpCVmhQMDNEREh2dmhUWDRMQURYY1diQ2xrRlhJSW9u?=
 =?utf-8?B?QnpOTGF4Z2tyL2N5cHlIRzVmZmpqRXRNMCtYZ2VEazBZVUdtblBZWWY2MEVC?=
 =?utf-8?B?SWhkcE5mMHJKR1hkR1pDWVdBRzhVMkQzTWdSSWx0YXJyQmhQamVDRGIyTngz?=
 =?utf-8?B?S21zQ1JreERJbzRrU1J1TVZTS0E0L2Nwb2NsM0QvQ0FXYXBUVktWVzYrVjJL?=
 =?utf-8?B?UEx2eVNueUQ0b3AwV3MxTjd2OHZGdXhLTlAyZ3NyUGc3ZDJMTUNnQ1lhdVla?=
 =?utf-8?B?QmlTYTYvQjhDNEE4RmJ4OTB2aDdDQVEzOXM1N01iVGlaZmo4U214YUNYbHBt?=
 =?utf-8?B?QzhCRWJWSUZ6bFhIYUxtRlF1di8raWFvWUpJSnJEb3ZTOU9kWHFkQnVHTDVP?=
 =?utf-8?B?ZmhDU21OY2k2UmhSUHJQczBmY2pWR3hTRUFsK0tMZWsvVm1GV0ZHdjNJWlJ1?=
 =?utf-8?B?MHBhaGE5bW81QzFheHI0MlBNUjdWN1E3WUtEVy9vQTcreitRWkxtcW1RS0NN?=
 =?utf-8?B?dlMvUUphS1NkSHMrL3dMc3Q0YzVmUEZidjRMUkQ4Q3F0SXVPYjVLRjdRYlpv?=
 =?utf-8?B?bFFJUThiNW5LWGpEMTYrL2F1L01iN2dFaTN0YlhuOFdqOHQyUkFLMktoSFFB?=
 =?utf-8?B?TjRIemUrWWRXeDlKaDdrUlhZeDBZZE1UVStkbVRNdFRvVlUzaDdsMWt2MlNa?=
 =?utf-8?B?NDFnZDN2YTNJODQ0czVJSnF4T01kVnVsV1lZcm9LRHUxNDNYWUw5LzZvSHUz?=
 =?utf-8?B?cUpYeUZjbXJFZ1YzeUxKU1ZOeXdVQU43OXRHRld5TDk0NUgxTUhyRHI5V1BM?=
 =?utf-8?B?TE1xeUNOWXhqWjB0ZlMxWkh5VXNVSXdyMHRhYy9ILy9LVEs2WGx0RjFqTXp4?=
 =?utf-8?B?ODRuNWM5MVpMQ1k0UTdKMkhxeUtNdnM1VHl6b01VeXdoZmNsZXk4R3NzbmJT?=
 =?utf-8?B?N3lEbURUN1Ayc1dUMEFzNWVZbkZtSlhLSXBHQktnY09TKzVHT1l4VElsbzg2?=
 =?utf-8?B?dGhhd3VoSksrZUZWTHRSTjJob2Z6dlJoaGJLNDVnNDZpbEMvTEFPM0s1SUlF?=
 =?utf-8?B?c0kyRm12VU0vQ3p3cTBGRmllbUg3cGMwVlBaV1JYTjhmZGVOQXJRNlc5ZVdt?=
 =?utf-8?B?YTk4bEYyUjBKaWdoaVM2S0p4enRwR0ovYmhUSjQ5RG1peXBhMVcvZHhUVHF2?=
 =?utf-8?B?T2RRMy9Ha0FvWnFOcEN6TjcwZ3o1V2xBWGdaTnludUt4UnFwU0FaMWhabzJF?=
 =?utf-8?B?djFoL1hyY3UxZVlIQksvSlpldExMa2FxVG5Sb0p0QU1YTVBKanVlZ0xodmpB?=
 =?utf-8?B?NDZZQmhPVy9hdHNjOTRySWR0M2pvMGN5WHFIZmlMT3EvdXNZckZtdEg2cjdh?=
 =?utf-8?B?aTFGcDdjREZWOTdOSmR5cThVWUVHb29LdUpEdFNMTkhpL3ZjWG9pakVMWHRC?=
 =?utf-8?B?cWNEcEp3NFE1SENtZDlUMmR0NEt0MmJvbFFKZGZVZG9wT1RlM2k1aFg4bUdR?=
 =?utf-8?B?UXJJelRMRDVrNWtjQ203UTdvVzMxazU1bzk5VFh6ek05K2VwdlBCNmRSbDFq?=
 =?utf-8?B?di9HYitCYTA2TjBBQkQwUTVCL3g0d3FpWUg4ZE5SMHpPL05qaWY3ZDZyMFY1?=
 =?utf-8?B?VlZwdHdVbzJoV2pmUWREdmZIK1ZhRGh3OTFDRkpiNnhBc2tQSUpCV0F6SzQw?=
 =?utf-8?Q?Faitd5jCZo8R8e7uttGy?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?V3pOaE9pbEJKYmc5SWV6RVJwa0pWdUo2cllZcnI1WFdIWjVoMXJFR3dJdUFB?=
 =?utf-8?B?alR3ckZWVUh6Y1pLZDJwN0hPL1oyV0QvdmRTK2ExYUdicVBUb1dncUs5bWxW?=
 =?utf-8?B?UUdYOVQrUmZ1elQ5eE9pbDU3UEVJMEQvQ3FLKzJuMzRrdUJjNk5GMkdoZzB1?=
 =?utf-8?B?aHBSTEc2Slc0dmJOT2hoK01ueE9lZFdyRVhFVXZUVzdqWTNGRWxqUVR6NnJU?=
 =?utf-8?B?M2diTGIrcUphL3drTWZoTmNMT0lEaG5CZUVjV0lLN1d2cEZuZC8wL0pjV0p4?=
 =?utf-8?B?RXFvRDhnY1k2MmV1WG1XN0p2b2NraTlnRDdCTTVCKzVkcktiS3o4V3N4bnZ3?=
 =?utf-8?B?Mzc4bHY5QnZielc0WGY1WXZhWEZKVkk3S0lsNG9iRDJ2ZnF5OU5PRUIxcDRl?=
 =?utf-8?B?YXNySytoejZaZ2t4Z1QrdVNUUlNmaUE0SXNIb3pMaXdBRXFHa3BDaUlPSWwv?=
 =?utf-8?B?dGc0c3dPbkVQQ2VkMlcvM0xIOW1QWnFKN0lqVGFhN3lxWG9ZQ09UZzhyYWtC?=
 =?utf-8?B?Y3k3SFlkSUs3K3V4QUJVQU40VFFqSXlJeU9Gb2hLbk56b1cwR1drRTM0RUJO?=
 =?utf-8?B?Z0hFYlg3OERVam9DcHBtdWhLMW9EanFsaU91clpaVGR1TU05bzNvU28rL0Zt?=
 =?utf-8?B?c2NGT3RUTXdUYU85UkQwK0RSbXdaakEwc2JKU3ZLZDQ1WDlKNzk4STFra1BZ?=
 =?utf-8?B?WFAzZmxET3YzdVNBWjJNNHMrYkJvOFNKa09iZndUNzcyUlV4TStCR1cybXJo?=
 =?utf-8?B?UDZmS0tHc2xEK3I3alk1ZXlsdkpUaGpBME41VjNaYmhSaU1VTXNpMzYvUmtR?=
 =?utf-8?B?MVZSWldHNmg4eUIzdm1uU1V3WWM4T1JPdmZUOTZKWGFYNGdvTE1PcXVIUGc1?=
 =?utf-8?B?U0xlMzR1YWtFQVYvZUp4QVB0YVh4WmUwSjdOdzBjM1B0S3lvaWlvVFZoNXNI?=
 =?utf-8?B?S3dqazJ2MFk0bFFtTXZlUTVhTHRxOVRldHl5V0hxYW0zNy9UY05Nb05MOUIx?=
 =?utf-8?B?ZmNVRVZZdlpNL0JJeFdTajZTTGJjUjJVU1Y4Z2Y2S3FGMWdnSHlQcUZ6d1pY?=
 =?utf-8?B?czRjbDRKOEZWZDZHaEU4MGRTSzhRMm5pUTREYWMwbzJGZ3JJK3VsN2RSYVhN?=
 =?utf-8?B?TjBVSlpMcko5YkpkTlZSQVBuUWovWXhzdFdUUGdncGhSMFhmRm5GUWZyNCtP?=
 =?utf-8?B?Nkt6bEFjaTVVNmd2UldnNzBHaUVlcGNBL0NacEpMOEdvVm5mckN2aFREZWUz?=
 =?utf-8?B?YUplN3o2dkdVTkZ6dE5Rck10STA2Q0JCMEJyNGZYUzVqVktaNWg3YTRLNHdR?=
 =?utf-8?B?cEx0ZXd0bmJiS29FL1F5akZvSlN4TVRIRlZJN2tESW1kRzREd2ZIdkx1SHBj?=
 =?utf-8?B?NUd2YlI1UDQxUkJnSEQ3emdPMHNUZ0srUlZreis0ZEwzczNWUFFzQ3dFS00z?=
 =?utf-8?B?b2hwUFNEOTlWNFRVTmwvd1VaVEI1Ynh1SG92T3BaNm9hNGczaWtWSGF4VENy?=
 =?utf-8?B?bUdpUEJsTVgxQXdVSGx3VlJDR05VSzhNTGdtS2JEMitzeVJqV05wZnZjVitz?=
 =?utf-8?B?a1BPR2Q4VWI1Tkl0dkdyeCt1cmQzVzBjaWRKaTVSYzlNR2crQzR6elZ0bDVq?=
 =?utf-8?B?QlM5U0FlOWdFV2IzSmVNWWxNRVM5NDVlS3lXNHB1eEgrZitNYUtSRFNsZ1k0?=
 =?utf-8?B?WlJhZU83dVV1MmQwbjl0TkZMM0tvb2U2K3JpSENrZnhueER3NE9SV0RSd3Vs?=
 =?utf-8?Q?MUORO08dvhchXZ/pf8=3D?=
X-OriginatorOrg: sct-15-20-8534-15-msonline-outlook-5f066.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: d7585d5f-6ea9-4f30-f3f6-08de29829eb3
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2025 04:50:12.2178
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2P250MB0319
From: bobwei9@hotmail.com (Bob Weinand)

--------------YIXyEIZ5LWIn7fiGhFHcUghb
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Jakub,

On 21.11.2025 12:29:16, Jakub Zelenka wrote:
> Hi,
>
> I think you seriously underestimate impact of this in the current PHP 
> code bases where many applications depend on global state. Especially 
> the legacy ones but even the most popular ones. Just look into 
> WordPress which use global state extensively. Now imagine that some 
> popular plugin decides to use async which change some of its globals 
> (like $post or $wp_query) during the suspension of the main code. I 
> would assume this could horribly break things. Don't forget that other 
> code don't have control over the plugin and it might not even know 
> that async is used there. So I'm not sure if this design is compatible 
> with WordPress and similar applications where global state is used 
> extensively. If that's the case, it's of course a problem because 
> those applications (well WordPress on its own in fact) compose the 
> majority of PHP users so introducing something that would have 
> potential to break its code would limit usability of the whole feature 
> and could even lead to loosing more users that we could gain from 
> introducing this feature.
>
> So I think it will need to find some solution that will prevent this 
> from happening. I guess there might be few options
>
> 1. Disallow suspension of the main sync code which is effectively some 
> sort of colouring.
> 2. Preventing access to globals from coroutine which I'm not sure is 
> even fully doable from the engine PoV - it would mean some sort of 
> different execution mode that could not use globals (e.g. global 
> keyword and calling some functions that change global state). It would 
> need channels for communications between coroutines. The advantage of 
> such model would be possibility to combine it with threads in the 
> future but I could imagine it could still lead to some subtle issue 
> for years as there is internal global state as well that can lead to 
> some surprises. But maybe that would be worth it.

I think you seriously misunderstand this.

Async does not allow you to introduce some effects from the outside. You 
have to actively opt-in to running stuff in parallel.

The problematic part, is, when you call code inside of coroutines, which 
is not safe to be run in parallel with other code.

I.e. if you start writing code like `await([new Coroutine(fn() => 
not_safe_to_run_twice()), new Coroutine(fn() 
=> not_safe_to_run_twice())])` (pseudo code). 
Where not_safe_to_run_twice() shares some context.

So, when you write async code, you have to *know* that the called code 
is allowed to run in parallel with any other code which you explicitly 
chose to run in parallel with it. E.g. if you'd run two wordpress 
functions which don't have side-effects (not even to internal state), 
then you're perfectly fine doing that. If you run wordpress functions in 
parallel which may jump back to the scheduler during its operation and 
leave the internal state in some intermittently invalid form, then yes, 
then you have a problem.

But if your goal is to just do a localized parallelized operation which 
you know is safe to run in parallel - e.g. some image processing and 
storing some stuff in the database, within your wordpress plugin, that's 
absolutely fine. It won't break anything.


Essentially: Just don't call stuff in parallel which you don't know is 
safe to be called in parallel and you're golden.


Bob

--------------YIXyEIZ5LWIn7fiGhFHcUghb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hey Jakub,</p>
    <div class="moz-cite-prefix">On 21.11.2025 12:29:16, Jakub Zelenka
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com">
      
      <div dir="ltr">
        <div>Hi,</div>
        <br>
        <div class="gmail_quote gmail_quote_container">
          <div>I think you seriously underestimate impact of this in the
            current PHP code bases where many applications depend on
            global state. Especially the legacy ones but even the most
            popular ones. Just look into WordPress which use global
            state extensively. Now imagine that some popular plugin
            decides to use async which change some of its globals (like
            $post or $wp_query)&nbsp;during the suspension of the main code.
            I would assume this could horribly break things. Don't
            forget that other code don't have control over the plugin
            and it might not even know that async is used there. So I'm
            not sure if this design is compatible with WordPress and
            similar applications where global state is used extensively.
            If that's the case, it's of course a problem because those
            applications (well WordPress on its own in fact) compose the
            majority of PHP users so introducing something that would
            have potential to break its code would limit usability of
            the whole feature and could even lead to loosing more users
            that we could gain from introducing this feature.</div>
          <div><br>
          </div>
          <div>So I think it will need to find some solution that will
            prevent this from happening. I guess there might be few
            options</div>
          <div><br>
          </div>
          <div>1. Disallow suspension of the main sync code which is
            effectively some sort of colouring.</div>
          <div>2. Preventing access to globals from coroutine which I'm
            not sure is even fully doable from the engine PoV - it would
            mean some sort of different execution mode that could not
            use globals (e.g. global keyword and calling some functions
            that change global state). It would need channels for
            communications between coroutines. The advantage of such
            model would be possibility to combine it with threads in the
            future but I could imagine it could still lead to some
            subtle issue for years as there is internal global state as
            well that can lead to some surprises. But maybe that would
            be worth it.</div>
        </div>
      </div>
    </blockquote>
    <p>I think you seriously misunderstand this.</p>
    <p>Async does not allow you to introduce some effects from the
      outside. You have to actively opt-in to running stuff in parallel.</p>
    <p>The problematic part, is, when you call code inside of
      coroutines, which is not safe to be run in parallel with other
      code.</p>
    <p>I.e. if you start writing code like `await([new Coroutine(fn()
      =&gt; not_safe_to_run_twice()),&nbsp;new Coroutine(fn() =&gt;&nbsp;not_safe_to_run_twice())])`
      (pseudo code). Where&nbsp;not_safe_to_run_twice() shares some context.</p>
    <p>So, when you write async code, you have to *know* that the called
      code is allowed to run in parallel with any other code which you
      explicitly chose to run in parallel with it. E.g. if you'd run two
      wordpress functions which don't have side-effects (not even to
      internal state), then you're perfectly fine doing that. If you run
      wordpress functions in parallel which may jump back to the
      scheduler during its operation and leave the internal state in
      some intermittently invalid form, then yes, then you have a
      problem.</p>
    <p>But if your goal is to just do a localized parallelized operation
      which you know is safe to run in parallel - e.g. some image
      processing and storing some stuff in the database, within your
      wordpress plugin, that's absolutely fine. It won't break anything.</p>
    <p><br>
    </p>
    <p>Essentially: Just don't call stuff in parallel which you don't
      know is safe to be called in parallel and you're golden.</p>
    <p><br>
    </p>
    <p>Bob</p>
  </body>
</html>

--------------YIXyEIZ5LWIn7fiGhFHcUghb--