Re: [RFC] Add num_available_processors

On 5/24/25 15: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?

Are you suggesting that the function itself not be available or that it throws when you attempt to call it on a system that doesn't support it? I don't like the idea of the function not being available if the system doesn't support the functionality. Users would have to call function_exists() before using the function, in those cases. Random thought: if the system doesn't support the functionality, would it be wrong to respond with a default value of 1 or 0? Presumably, all systems have at least 1 core (maybe that's a naïve assumption). (I'm not in favor of this approach—it's just a random thought.) IMO, it's best to throw an exception when calling the function if the system doesn't support it. Cheers, Ben

Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc