Add variant of mutex based on flock #80
Conversation
src/FileMutex.php
Outdated
| @@ -20,39 +19,16 @@ public function __construct(private readonly string $fileName) | |||
|
|
|||
| public function acquire(): Lock | |||
| { | |||
| // Try to create the lock file. If the file already exists, someone else | |||
| // has the lock, so set an asynchronous timer and try again. | |||
| $f = \fopen($this->fileName, 'c'); | |||
There was a problem hiding this comment.
This is a one-time cost, not really worth adding a touch here imo
src/FileMutex.php
Outdated
| $lock = new Lock($this->release(...)); | ||
|
|
||
| $file->close(); | ||
| $lock = new Lock(fn () => \flock($f, LOCK_UN)); |
There was a problem hiding this comment.
This will block for a short duration, no?
There was a problem hiding this comment.
I considered adding a variant that used parallel but decided that the overhead to communicate to/from the IPC worker will be way worse than that of a single syscall that returns immediately.
|
The disadvantage is that these files will stay in the filesystem. We should likely ship it as a new implementation rather than replacing the existing one? |
|
I believe there is no reason to add yet another implementation instead of fixing the existing broken one. |
|
The fact that lockfiles aren't deleted is not a downside, it's precisely the reason why the new implementation is better than the old one. |
|
That totally depends on the usage of the library. If you're using lots of dynamic files for locks, they'll quickly pile up now. |
danog
changed the title
|
Split the new mutex into a separate class. |
Fixes #79