Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126170
Message-ID: <9169e8f6-a25e-4b69-92fa-a70c0445273f@gmail.com>
Date: Sun, 22 Dec 2024 21:32:47 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Discussion: Remove file statcache?
To: internals@lists.php.net
References: <27531d9d-9bfe-4acc-b9ab-80b1017e3038@app.fastmail.com>
 <CAEKnhAFU32EXh483QzR0LLUt+Jou4ejKjOXqBQ_G43wR7LW5cA@mail.gmail.com>
 <ACB1A7C2-FAF5-4A43-BBB9-A3E8469E2385@rwec.co.uk>
 <21dd9ac7-e81b-4509-bfa4-a36d05237270@gmail.com>
 <F31E457C-B04D-41D3-A544-0A1E7F139261@rwec.co.uk>
 <614d3f45-0f54-4a2e-a21e-2eec5f496fa0@gmail.com>
 <22132ea8-9e5b-4688-9bf4-4a1972e347b1@rwec.co.uk>
Content-Language: en-US
In-Reply-To: <22132ea8-9e5b-4688-9bf4-4a1972e347b1@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

On 22/12/2024 13:16, Rowan Tommins [IMSoP] wrote:
> On 21/12/2024 20:50, Niels Dossche wrote:
>> Adding a parameter for a cache, which should've been transparent in the first place, to every file operation is messy.
> 
> 
> I would say it's less messy than having to work out when to turn a global setting on or off. In particular, it would be horrible for shared libraries, the equivalent of the above would be something like this:
> 
> $old_cache_setting = ini_set('enable_stat_cache', 1);
> $perms = fileperms($name); $size = filesize($name); ini_set('enable_stat_cache', $old_cache_setting);
> 
> Similarly, for the false case, library code would either have to assume the cache might be enabled, and call clearstatcache() just in case; or it would have to carefully wrap code in similar ini_set blocks.
> 
> As far as I can see, both code that benefits from the cache, and code that suffers from it, is very rare; but if you know you're writing one or the other, having an explicit way to mark *that code* seems more appropriate than toggling a global setting.

I see your argument (hah!) for shared libraries.
But the programmer effort of adding the extra argument to calls starts to outweigh the global ini setting approach quickly, as the global ini setting has a "fixed cost" of two lines of code while adding a parameter scales in the number of calls the programmer has to change.

> 
>> But if you want to add extra parameters to functions that can potentially touch the stat cache, then you need to take into account spl as well. Adding extra parameters to the functions in those classes are a BC break because the signature of potential userland function overrides would no longer be compatible at compile time.
> 
> 
> Ah yes, I hadn't thought of objects being affected. On the other hand, objects have an obvious place to store both the state of the setting and the cache itself: on the instance.

I do agree with this yes.


All in all though, I'm not convinced by the parameter approach.
I'd like a proper solution rather than some plaster.
There are some options:
1) Try to fix the stat cache.
2) Put stat cache behind an ini knob.
3) Get rid of the stat cache.

All of these simplify the developer experience. Adding more configuration knobs or extra parameters add complexity.
I'd like to see more simplification.

Kind regards
Niels