Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129435
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
 <2015208655.784984.1763811978476@email.ionos.de> <CAMW7n8D0=6hEPpZpGe2SrYKqgFqsDkPAjHBP4g5K45bFPaiNdw@mail.gmail.com>
 <980296152.1071.1763813573083@email.ionos.de> <CAMW7n8DXA501uGOY3952y8YhAJDVRrPYEiuw+Wzc5=oEciLVZQ@mail.gmail.com>
 <92865666.4510.1763818506332@email.ionos.de> <CAMW7n8AycfX4NMfjJ+GzFsPqRaSae-t7Cm3H5z8apRzXUgaVZw@mail.gmail.com>
 <329450798.8037.1763822426377@email.ionos.de> <CAMW7n8DTt2S_RfcyshERixed=qqyFUPEvWp_MpgpW_CvH3urXQ@mail.gmail.com>
 <CAMW7n8CUQxqh4_rTWQBcj+t17i5oW7x-V96FSkwZL85Z2pzrRw@mail.gmail.com>
 <CAB9bCb34cmu9=an9K4rubPSVEDwyWH-rMAVtTTYa3U-LA+GJ+A@mail.gmail.com>
 <CAMW7n8DM4MCP25gSLBbd3+Awzs2+p6Qs_jPgx1mk=RjSVe+iUw@mail.gmail.com>
 <9287c46c-bc63-4dd0-9792-0f9421959589@rwec.co.uk> <CAMW7n8AhbBawCBtfNJZ6XzFSvwhtZotfgBmb1O4CDZ+J2jxt2w@mail.gmail.com>
 <C766271D-EE7A-4727-8A7C-B117429768E5@rwec.co.uk> <CAMW7n8Bk+AhbXjg8QADFo=2k9qCE54DD68Hxkf2k_9J=EFboUQ@mail.gmail.com>
 <65869feb-d518-4de3-8c10-115e3ba7dce7@rwec.co.uk>
In-Reply-To: <65869feb-d518-4de3-8c10-115e3ba7dce7@rwec.co.uk>
Date: Mon, 24 Nov 2025 16:46:20 +0100
Message-ID: <CAB9bCb3fyV6EkAp6Mv+5YPWHk9CMKSXd0pmj3sDb3cJS34t6DQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000376e350644591136"
From: bart+php@croquemonsieur.be (Bart Vanhoutte)

--000000000000376e350644591136
Content-Type: text/plain; charset="UTF-8"

Op ma 24 nov 2025 om 15:03 schreef Rowan Tommins [IMSoP] <
imsop.php@rwec.co.uk>:

> - SDK Susie does not know what implementation of LoggerInterface will be
> passed to her library. How does she know if it is safe to use in her
> asynchronous code?

As the LoggerInterface is injected into her SDK client and there is no
distinction between an async and a sync Interface, Susie can't and doesn't
really need to know this. She just uses the contract that is implied by the
interface.

> - Legacy Les is using a LoggerInterface implementation written years
> ago. How does he know whether it is acceptable for use with Susie's
library?

As I see it, there's two kinds of "acceptable" in this case: blocking vs
non-blocking and possible side effects.

Blocking vs non-blocking:
If Les does not care about blocking the event loop he can do whatever he
wants. If he passes a Logger with a blocking I/O call (for example through
some extension) the event loop would block for the duration of the I/O
call. Acceptable in his case, as he does not seem to care about async.
If Les wants to take advantage of non-blocking I/O he has to use a Logger
which implements one of the non-blocking I/O functions (file_put_contents,
...). In this case I would expect the Scheduler to await that function call
in the current coroutine. Is this correct Edmond?

Possible side-effects:
It is however possible that the expected output of the logs may have a
different order than before Susie migrated her library from sync to async.
Depending on how you look at it this might be a problem. I would expect
Susie to release a new major version warning users of a possible break in
backward compatibility. If Susie does not do that, Susie is at fault. If
Susie does release a new major version I would expect Les to fix his
dependency on shared state before upgrading to a new major version instead
of blindly upgrading to a new version*.

* which he shouldn't do anyways, async or not.

Is this helpful?

Best Regards,
Bart Vanhoutte

--000000000000376e350644591136
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op ma 24 nov 2025 om 15:03 schreef Rowan Tommins [IMSoP] &=
lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt;:<br=
><br>&gt; - SDK Susie does not know what implementation of LoggerInterface =
will be<br>&gt; passed to her library. How does she know if it is safe to u=
se in her<br>&gt; asynchronous code?<div><br></div><div>As the LoggerInterf=
ace is injected into her SDK client and there is no distinction between an =
async and a sync Interface, Susie can&#39;t and doesn&#39;t really need to =
know this. She just uses the contract that is implied by the interface.</di=
v><div></div><div><br></div><div>&gt; - Legacy Les is using a LoggerInterfa=
ce implementation written years<br>&gt; ago. How does he know whether it is=
 acceptable for use with Susie&#39;s library?<br><br>As I see it, there&#39=
;s two kinds of &quot;acceptable&quot; in this case: blocking vs non-blocki=
ng and possible side effects.</div><div><br></div><div>Blocking vs non-bloc=
king:<br>If Les does not care about blocking the event loop he can do whate=
ver he wants. If he passes a Logger with a blocking I/O call (for example t=
hrough some extension) the event loop would block for the duration of the I=
/O call. Acceptable in his case, as he does not seem to care about async.</=
div><div>If Les wants to take advantage of non-blocking I/O he has to use a=
 Logger which implements one of the non-blocking I/O functions (file_put_co=
ntents, ...). In this case I would expect the Scheduler to await that funct=
ion call in the current coroutine. Is this correct Edmond?</div><div><br></=
div><div>Possible side-effects:<br>It is however possible that the expected=
 output of the logs may have a different order than before Susie migrated h=
er library from sync to async. Depending on how you look at it this might b=
e a problem. I would expect Susie to release a new major version warning us=
ers of a possible break in backward compatibility. If Susie does not do tha=
t, Susie is at fault. If Susie does release a new major version I would exp=
ect Les to fix his dependency on shared state before upgrading to a new maj=
or version instead of blindly upgrading to a new version*.</div><div><br>* =
which he shouldn&#39;t do anyways, async or not.<br><br></div><div>Is this =
helpful?<br><br>Best Regards,<br>Bart Vanhoutte<br><br></div></div>

--000000000000376e350644591136--