Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127449
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 24 May 2025 22:43:01 +0200
To: internals@lists.php.net
Message-ID: <36cd6421-482e-4699-858b-660e2128c0f1@app.fastmail.com>
In-Reply-To: <57f7ed3e-6bef-434d-83db-fd729ff43fc9@gmail.com>
References: <bc1ec15125844c78a6aa23dce6148af9@danielkesselberg.de>
 <8b76a3d4-4583-4849-a75f-00f645191247@gmail.com>
 <db784868-187d-42ff-9575-64b5ca70f50b@app.fastmail.com>
 <57f7ed3e-6bef-434d-83db-fd729ff43fc9@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Add num_available_processors
Content-Type: multipart/alternative;
 boundary=a8d4207f4a50441282a28ba0ea9d4e3e
From: rob@bottled.codes ("Rob Landers")

--a8d4207f4a50441282a28ba0ea9d4e3e
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, May 24, 2025, at 22:28, Niels Dossche wrote:
> On 24/05/2025 21:24, Rob Landers wrote:
> >=20
> >=20
> > On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
> >> Hi
> >>
> >> In my opinion, the return type should not be nullable.
> >> Returning NULL when the platform (or PHP on that platform) doesn't =
support getting this information is an anti-pattern.
> >> Instead, availability of the necessary functionality should be chec=
ked at configure time and the function should be made conditionally avai=
lable.
> >> That way, the return type can just be "int".
> >>
> >> Kind regards
> >> Niels
> >>
> >=20
> > I=E2=80=99m curious why you say this is an =E2=80=9Canti pattern=E2=80=
=9D? I do agree that it should return a number or throw.
>=20
> If you make the function unconditionally available, yet specifying the=
 return type as ?int, then you give the false impression that it _can_ w=
ork even if your platform doesn't support it.
>=20
> Also: IMO new APIs should fail hard with an exception if they can't do=
 their main task, that's our error "channel".
>=20
> > There are various error conditions it should throw (at least on Linu=
x) so having it throw an exception when there isn=E2=80=99t a way to cou=
nt any processors makes more sense than returning null.
>=20
> Throwing is indeed preferable.
> What are the error conditions on Linux?
>=20
> >=20
> > It could also be someone patching libc to get around per-core licens=
ing too. I=E2=80=99ve seen the latter more often than the former.=20
> I don't follow.
> In any case, if you run a monkey patched libc and you're breaking the =
consumer expectations of said libc, then you deserve getting it blown up=
 in your face imo.
>=20
> Kind regards
> Niels
>=20

I think we both agree it should blow up.

Error conditions (for Linux) using the current method in the patch are e=
ither -1 or 0. -1 is just a possible return for that function which coul=
d indicate that the kernel doesn=E2=80=99t have support for that sysconf=
 value or there are infinite cores =E2=80=94 you=E2=80=99d have to check=
 errno.=20

It might also report 0, which technically isn=E2=80=99t an error (hotplu=
gging cpus for instance). It could also just be a bug. This is a fun one=
: https://github.com/lxc/lxcfs/issues/469

Also, I wouldn=E2=80=99t be surprised to see a container with very small=
 amounts of cpu allocated getting rounded to zero. But in any case, zero=
 should probably be treated as an error IMHO.

=E2=80=94 Rob
--a8d4207f4a50441282a28ba0ea9d4e3e
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, May 24, 2025, at 22:28, Niels Dossche wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 24/05/2025 21=
:24, Rob Landers wrote:</div><div>&gt;&nbsp;</div><div>&gt;&nbsp;</div><=
div>&gt; On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:</div><div>=
&gt;&gt; Hi</div><div>&gt;&gt;</div><div>&gt;&gt; In my opinion, the ret=
urn type should not be nullable.</div><div>&gt;&gt; Returning NULL when =
the platform (or PHP on that platform) doesn't support getting this info=
rmation is an anti-pattern.</div><div>&gt;&gt; Instead, availability of =
the necessary functionality should be checked at configure time and the =
function should be made conditionally available.</div><div>&gt;&gt; That=
 way, the return type can just be "int".</div><div>&gt;&gt;</div><div>&g=
t;&gt; Kind regards</div><div>&gt;&gt; Niels</div><div>&gt;&gt;</div><di=
v>&gt;&nbsp;</div><div>&gt; I=E2=80=99m curious why you say this is an =E2=
=80=9Canti pattern=E2=80=9D? I do agree that it should return a number o=
r throw.</div><div><br></div><div>If you make the function unconditional=
ly available, yet specifying the return type as ?int, then you give the =
false impression that it _can_ work even if your platform doesn't suppor=
t it.</div><div><br></div><div>Also: IMO new APIs should fail hard with =
an exception if they can't do their main task, that's our error "channel=
".</div><div><br></div><div>&gt; There are various error conditions it s=
hould throw (at least on Linux) so having it throw an exception when the=
re isn=E2=80=99t a way to count any processors makes more sense than ret=
urning null.</div><div><br></div><div>Throwing is indeed preferable.</di=
v><div>What are the error conditions on Linux?</div><div><br></div><div>=
&gt;&nbsp;</div><div>&gt; It could also be someone patching libc to get =
around per-core licensing too. I=E2=80=99ve seen the latter more often t=
han the former.&nbsp;</div><div>I don't follow.</div><div>In any case, i=
f you run a monkey patched libc and you're breaking the consumer expecta=
tions of said libc, then you deserve getting it blown up in your face im=
o.</div><div><br></div><div>Kind regards</div><div>Niels</div><div><br><=
/div></blockquote><div><br></div><div>I think we both agree it should bl=
ow up.</div><div><br></div><div>Error conditions (for Linux) using the c=
urrent method in the patch are either -1 or 0. -1 is just a possible ret=
urn for that function which could indicate that the kernel doesn=E2=80=99=
t have support for that sysconf value or there are infinite cores =E2=80=
=94 you=E2=80=99d have to check errno.&nbsp;</div><div><br></div><div>It=
 might also report 0, which technically isn=E2=80=99t an error (hotplugg=
ing cpus for instance). It could also just be a bug. This is a fun one:&=
nbsp;<a href=3D"https://github.com/lxc/lxcfs/issues/469">https://github.=
com/lxc/lxcfs/issues/469</a></div><div><br></div><div>Also, I wouldn=E2=80=
=99t be surprised to see a container with very small amounts of cpu allo=
cated getting rounded to zero. But in any case, zero should probably be =
treated as an error IMHO.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--a8d4207f4a50441282a28ba0ea9d4e3e--