Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129372 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 lists.php.net (Postfix) with ESMTPS id 31AD01A00BC for ; Fri, 21 Nov 2025 14:47:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763736453; bh=D0bz6G0SeFDpaLj3y8BbDzESTKN1Jay3fPsmqJizAMQ=; h=References:In-Reply-To:From:Date:Subject:To:From; b=YK16SXmspj+6HX2ovIPi1DhfQHtN91ivPWTYrhxRoqSGAEFxlVshY8JZ6lZeH6NEQ 3lf5UsOD8OgXlnfTZSYarnm30IRYOSV/mY4Idf4w6oXxVLu6TbkpAW6zxFboMUNoDm Ot+pgVdURqkjytClbtiZZB1AzZPX3GrS1mVHSlKZQVs24UiJXtP3bQk6pOwUAO8kaM PoPpkLDOUmw8/Yc7h35bYO63T+VAfnFqzLi51UzSXvy8isgxjQ7gaYZh3Xd7vF1SYU MalhOgmRiEjdDgvh6+4vhO4+8Y0iVPFyYd2QFV7YWLcmV4yu8S/1T7huwLNU5dnyTW QqNf7zQOozamQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DFBE21804F3 for ; Fri, 21 Nov 2025 14:47:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 ; Fri, 21 Nov 2025 14:47:32 +0000 (UTC) Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-6418738efa0so3477180a12.1 for ; Fri, 21 Nov 2025 06:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=croquemonsieur-be.20230601.gappssmtp.com; s=20230601; t=1763736444; x=1764341244; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=D0bz6G0SeFDpaLj3y8BbDzESTKN1Jay3fPsmqJizAMQ=; b=Uj8AlrAVk2TzkcAlP8F+bdOM1BQ2AMn2mg5Lm9v+qjsBNS2JXpKEsRSJV1OY/japG9 YGlpnkaangK0llSiGvbNFRnAx8JFjlKsCOv4U9CSSU0Vqi+lkhI0SrmiFy3or10hZEBE sI6W4djCthc9mX+ienuNPyWXBhOvV/GAQhDkddDvUCZlHi1W16GT0pOp01KNpuu8RmHg K8i+5LM+sNOrvHLIbeimPq0B+1q1XCirsMbi0+6Gu0t0FDD/HVpCN9EvU+sBWw0SXEGE Sw6VaxFb7BoUeyYQ09m+Y+W+hbrUgZJjDwkxqCefRjxocPL96G14UvsdYJTHv2Vs9fra Sp4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763736444; x=1764341244; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D0bz6G0SeFDpaLj3y8BbDzESTKN1Jay3fPsmqJizAMQ=; b=JE/3xE1R5dIZNLlQwGFqdFEMExYAaZXnhutKqvTDXMR8c8hTbO5x8J25ucLA1eRFHl iZ4jbZlI3bdsfMgFdL2zu7VJyNr00T34aXJ7ZOJcF7Lld/GMvtPZdI/7+LdXdnmwiwtj nVSOjm/Cn92JM5TvNm01QA5IcHAF4uNHy5bj1Grc1SfXlcCkwf7Ky3azdfSdkKvNND9a 0e71pSYPDxSjWw1apyQ6ZN5DeoFlYukMZuxeHgbrZ+ZnjScDqH2WlIzuEOAnYEGe7fvQ N2FtvNVHNPU/30w0gu/ippAyrSdwtiEJ1DwrnfHWiCeWocvxhH2ZqGEkf6+rQVv0mJ7b m/8Q== X-Gm-Message-State: AOJu0Ywspe2rxqjemCMJMwtPJ4Caan7bRZS83mCvyzEnVR/uysZdPE7U ZL6MW6ZHkm0vzOwC8uwdMrGVTAEeKQcDPwgzwyrTJacvEOEy+bnrAdT3LlEKoiYzDiMr+i+zvT1 5LJVvA4Uu6uwRlyLpPjj0KGaWm5W5TR57s8SZo5fV+fo0vIlVMJzF4EA= X-Gm-Gg: ASbGncvQUsI+B/pUMrV5tk40B7UAi6irMVhwWGV5Ks2yGWuzFhjIl+OoXO3CU7O3JIs 7Eb0nIjQSFtN7Bn7ktlJwLNxcpXSglp8TDEmdfrLqJYAdNOjmjsuIQmugOl5v2i03ynJc0nnQ3B gshWLpvn2bpYpw8AHLb8EDRed+D0A7tuZdOWGvQ6zxAcg5v+gg623p+/7ygv4ZgbJ8pwr9d9LlK 3jCqrqkemhuoj9LAYe3dXrdNpgkyZGUPcp+XsmJnX45TK+GxlVE5XJxdB/xZjzB5BX2qgzMX3X5 SewOjNK6cjZJ/vzdaqs++Kv4xhYx X-Google-Smtp-Source: AGHT+IFE6V7qoVVXEtav9hGSaOLCLlnJO5cyhEyIbhy2fpkQuIzsFimCEWMgwEwDMGytLT+aWHYpCUdaxg557dc3A2M= X-Received: by 2002:a17:907:97cc:b0:b73:9e51:7f with SMTP id a640c23a62f3a-b7671565480mr253567266b.22.1763736444263; Fri, 21 Nov 2025 06:47:24 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 21 Nov 2025 15:47:10 +0100 X-Gm-Features: AWmQ_bnyz-2YslONg1_eEvuby3221akYpXRMuZMfChF7uQXTl5SFUWpbbEwiGZI Message-ID: Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6 To: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000003cf29006441be42b" From: bart+php@croquemonsieur.be (Bart Vanhoutte) --0000000000003cf29006441be42b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > As long as the > transaction has not been committed or rolled back, the second > coroutine will execute queries on the same connection! *transaction, the second coroutine will execute queries on the same transaction. Op vr 21 nov 2025 om 15:38 schreef Bart Vanhoutte < bart+php@croquemonsieur.be>: > > ini settings are very frowned upon, but for the sake of a conversation, > we can think of it like that. if I do async.enabled =3D 0, then nothing > changes for me. Having this opt-in/opt-out control would mean that a brok= en > website caused by spawn() only happens if they decide to enable async and > they can start learning and developing their mental habit about how to wo= rk > with async code. > > > Like I said in my previous email, having a feature flag like this > would be a reasonable compromise between adoption and backwards > compatibility. Shared state is definitely a problem but there's also > less obvious things that can go wrong. > > For example: database transactions are done on a per connection basis. > Sharing a single database connection for purposes other than queries > that read things is dangerous. Imagine starting a transaction in one > coroutine, doing a couple of inserts and then switching do a different > coroutine before committing the transaction. As long as the > transaction has not been committed or rolled back, the second > coroutine will execute queries on the same connection! > > As for the feature flag: I would prefer something that can be enabled > on a per-project basis. I'm guessing an ini-setting could work? You > can enable it in both the configuration and in code (index.php). > > As an addition, a flag in composer.json that indicates async behavior > would be a nice to have. It could warn users when they are requiring a > library that does not support async. > > Best Regards, > Bart Vanhoutte > > > Op vr 21 nov 2025 om 15:18 schreef Deleu : > > > > > > > > On Fri, Nov 21, 2025 at 10:45=E2=80=AFAM Edmond Dantes > wrote: > >> > >> > >> I have a mental habit: when I write asynchronous code, I always assume > >> that any object shared between coroutines can change at any moment. > >> Similarly, if you hand off memory ownership to another class or share > >> memory, you have to keep in mind that there is a chance some developer > >> might accidentally do something wrong. > >> > >> The only difference between synchronous and asynchronous code is that > >> you don=E2=80=99t have a precise moment in time when the change happen= s. And > >> yes, that makes debugging harder. It makes finding bugs harder. But > >> it=E2=80=99s not something fundamentally new. > > > > > > I don't know how else to describe it, but I decided to give a last > attempt here since you mentioned your mental habit: having a mental habit > about async code makes perfect sense. What I'm trying to say is that most > PHP developers don't have that mental habit and that's not a problem > because Async code in PHP doesn't come into your project out of nowhere. > With `spawn()` being native, anytime you do "composer update" your projec= t > may start running async code without your consent and without warning you > that you should go through a mental habit that you don't even know exist > because you never had to worry about async code before in your life. > > > > Having spawn() be an extremely easy way to start running async code is = a > great feature (not a bug). But the very first thing that seems to be > missing is: I'm a dumb PHP developer that don't know and don't care about > async php and when I upgrade to PHP X.Y, how do I keep my project > always-sync without risking one of my composer packages suddenly calling > spawn() and causing bugs I have no idea how to even begin to understand? > > > > ini settings are very frowned upon, but for the sake of a conversation, > we can think of it like that. if I do async.enabled =3D 0, then nothing > changes for me. Having this opt-in/opt-out control would mean that a brok= en > website caused by spawn() only happens if they decide to enable async and > they can start learning and developing their mental habit about how to wo= rk > with async code. > > > > -- > > Marco Deleu > --0000000000003cf29006441be42b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As long = as the
transaction has not been committed or rolled back, the second
= coroutine will execute queries on the same connection!
*transaction, the second coroutine will execute queries on the same transa= ction.=C2=A0


Op vr 21 nov 2025 om 15:38 schr= eef Bart Vanhoutte <bart= +php@croquemonsieur.be>:
> ini settings are very frowned upon, but for the sake o= f a conversation, we can think of it like that. if I do async.enabled =3D 0= , then nothing changes for me. Having this opt-in/opt-out control would mea= n that a broken website caused by spawn() only happens if they decide to en= able async and they can start learning and developing their mental habit ab= out how to work with async code.


Like I said in my previous email, having a feature flag like this
would be a reasonable compromise between adoption and backwards
compatibility. Shared state is definitely a problem but there's also less obvious things that can go wrong.

For example: database transactions are done on a per connection basis.
Sharing a single database connection for purposes other than queries
that read things is dangerous. Imagine starting a transaction in one
coroutine, doing a couple of inserts and then switching do a different
coroutine before committing the transaction. As long as the
transaction has not been committed or rolled back, the second
coroutine will execute queries on the same connection!

As for the feature flag: I would prefer something that can be enabled
on a per-project basis. I'm guessing an ini-setting could work? You
can enable it in both the configuration and in code (index.php).

As an addition, a flag in composer.json that indicates async behavior
would be a nice to have. It could warn users when they are requiring a
library that does not support async.

Best Regards,
Bart Vanhoutte


Op vr 21 nov 2025 om 15:18 schreef Deleu <deleugyn@gmail.com>:
>
>
>
> On Fri, Nov 21, 2025 at 10:45=E2=80=AFAM Edmond Dantes <edmond.ht@gmail.com> w= rote:
>>
>>
>> I have a mental habit: when I write asynchronous code, I always as= sume
>> that any object shared between coroutines can change at any moment= .
>> Similarly, if you hand off memory ownership to another class or sh= are
>> memory, you have to keep in mind that there is a chance some devel= oper
>> might accidentally do something wrong.
>>
>> The only difference between synchronous and asynchronous code is t= hat
>> you don=E2=80=99t have a precise moment in time when the change ha= ppens. And
>> yes, that makes debugging harder. It makes finding bugs harder. Bu= t
>> it=E2=80=99s not something fundamentally new.
>
>
> I don't know how else to describe it, but I decided to give a last= attempt here since you mentioned your mental habit: having a mental habit = about async code makes perfect sense. What I'm trying to say is that mo= st PHP developers don't have that mental habit and that's not a pro= blem because Async code in PHP doesn't come into your project out of no= where. With `spawn()` being native, anytime you do "composer update&qu= ot; your project may start running async code without your consent and with= out warning you that you should go through a mental habit that you don'= t even know exist because you never had to worry about async code before in= your life.
>
> Having spawn() be an extremely easy way to start running async code is= a great feature (not a bug). But the very first thing that seems to be mis= sing is: I'm a dumb PHP developer that don't know and don't car= e about async php and when I upgrade to PHP X.Y, how do I keep my project a= lways-sync without risking one of my composer packages suddenly calling spa= wn() and causing bugs I have no idea how to even begin to understand?
>
> ini settings are very frowned upon, but for the sake of a conversation= , we can think of it like that. if I do async.enabled =3D 0, then nothing c= hanges for me. Having this opt-in/opt-out control would mean that a broken = website caused by spawn() only happens if they decide to enable async and t= hey can start learning and developing their mental habit about how to work = with async code.
>
> --
> Marco Deleu
--0000000000003cf29006441be42b--