Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[HttpKernel] Use flock() for HttpCache's lock files #19300
When a PHP process crashes or terminates (maybe the OOM killer kicks in or other bad things
The result is that other requests trying to access this cache entry will see a few seconds delay while waiting for the lock; they will eventually continue but send 503 status codes along with the response. The sudden buildup of PHP processes caused by the additional delay may cause further problems (sudden load increase).
I wrote this as bugfix against 2.7 because every once in a while I encounter situations (not always reproducible) where
Not sure this is the right approach: a real lock file will create another race condition unless the lock file is not unlinked (the race being when a lock is acquired but another process unlinks the just locked file).
@nicolas-grekas Not sure I got your above comment right
My intention was to use
Regarding the Windows tests, for some reason
Do you have any idea how I could debug this? I don't have a Windows machine with PHP set up anywhere near... :-(
We need to be sure of that. It will leave standalone files forever, and their number can grow large. Does it really not matter?
If we assume yes (which need confirmation), then maybe use flock directly here? The LockHandler only adds boilerplate to me in this case.
I am using
This PR places the lock files in the same directory as the cache entry in question. So I'd say yes, this can double the amount of files present in the
Now I get that: You cannot safely
My assumption was that all it does was to handle the edge-cases and platform inconsistencies of using file locking, tested and packed up behind a simple API. Don't you think I'd have to reinvent all this if I refrain from using