Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127448
Message-ID: <57f7ed3e-6bef-434d-83db-fd729ff43fc9@gmail.com>
Date: Sat, 24 May 2025 22:28:23 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Add num_available_processors
To: internals@lists.php.net
References: <bc1ec15125844c78a6aa23dce6148af9@danielkesselberg.de>
 <8b76a3d4-4583-4849-a75f-00f645191247@gmail.com>
 <db784868-187d-42ff-9575-64b5ca70f50b@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <db784868-187d-42ff-9575-64b5ca70f50b@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: dossche.niels@gmail.com (Niels Dossche)

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