Re: [RFC] Add num_available_processors

From: Date: Sat, 24 May 2025 20:43:01 +0000
Subject: Re: [RFC] Add num_available_processors
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message


On Sat, May 24, 2025, at 22:28, Niels Dossche wrote:
> On 24/05/2025 21:24, Rob Landers wrote:
> > 
> > 
> > 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 checked at configure
> >> time and the function should be made conditionally available.
> >> That way, the return type can just be "int".
> >>
> >> Kind regards
> >> Niels
> >>
> > 
> > I’m curious why you say this is an “anti pattern”? I do agree that it should return
> > a number or throw.
> 
> If you make the function unconditionally available, yet specifying the return type as ?int,
> then you give the false impression that it _can_ work even if your platform doesn't support it.
> 
> Also: IMO new APIs should fail hard with an exception if they can't do their main task,
> that's our error "channel".
> 
> > There are various error conditions it should throw (at least on Linux) so having it throw
> > an exception when there isn’t a way to count any processors makes more sense than returning null.
> 
> Throwing is indeed preferable.
> What are the error conditions on Linux?
> 
> > 
> > It could also be someone patching libc to get around per-core licensing too. I’ve seen
> > the latter more often than the former. 
> 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.
> 
> Kind regards
> Niels
> 

I think we both agree it should blow up.

Error conditions (for Linux) using the current method in the patch are either -1 or 0. -1 is just a
possible return for that function which could indicate that the kernel doesn’t have support for
that sysconf value or there are infinite cores — you’d have to check errno. 

It might also report 0, which technically isn’t an error (hotplugging 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’t 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.

— Rob


Thread (21 messages)

« previous php.internals (#127449) next »