On Sun, Dec 22, 2024 at 4:55 PM Calvin Buckley <cal...@cmpct.info> wrote:
> On Dec 22, 2024, at 10:57 AM, Kévin Dunglas <ke...@dunglas.fr> wrote: > > > > On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka <bu...@php.net> wrote: > > Thinking about it, there might be a possibility to address it (at least > on Linux) using fanotify. Not sure about other platforms but maybe there > are some solutions to address it. Also it might get a bit complex and not > sure how much the solution is viable. > > > > For FrankenPHP, we successfully use https://github.com/e-dant/watcher > for this kind of usage. It supports Linux (fanotify, notify, epoll...), > macOS, and Windows, and is very efficient. > > It's a C++ library but with pure C bindings. > > > > Best, > > I think watching files makes sense for FrankenPHP's use case of > development server, but I can't imagine the overhead and > non-portability makes sense for the stat cache. I feel any gains you'd > have from stat cache would be offset by that. And it'd be unfortunately > the only way to actually solve the "external thing changes thing behind > the stat cache's back" problem. Yeah I did some investigation and was thinking more about this. To make it effective, we would need a new thread that would poll the selected API and then clear the stat cache file (there would need to be a write lock for this ofc). We have actually another use case for this worker thread on ZTS MacOS in relation of timers which we were discussing some time ago - it could open path to removing the need for signals (e.g. possibly getting step closer to using goroutines for FrankenPHP). This was just for ZTS and we realised that for that we need a better event loop. We have got some plans for that but it might take some time to get there. But there is some possibility that we could eventually have it. It could also mean that we could extend that stat cache for more than the last file which could have some positive impact on perf. What we could do in the meantime is to do more aggressive flushing as mentioned in https://bugs.php.net/bug.php?id=72666 (comments). That could be potentially also applied as a bug fix (or at least some part of it and the more aggressive parts in master). It won't fix it completely but it might help with the most problematic issues. Regards Jakub