Skip to content

Conversation

danog
Copy link
Contributor

@danog danog commented Dec 9, 2023

Fixes #79

{
// 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');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not touch here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a one-time cost, not really worth adding a touch here imo

$lock = new Lock($this->release(...));

$file->close();
$lock = new Lock(fn () => \flock($f, LOCK_UN));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will block for a short duration, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@kelunik
Copy link
Member

kelunik commented Aug 31, 2024

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?

@danog
Copy link
Contributor Author

danog commented Sep 1, 2024

I believe there is no reason to add yet another implementation instead of fixing the existing broken one.

@danog
Copy link
Contributor Author

danog commented Sep 1, 2024

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.

@kelunik
Copy link
Member

kelunik commented Sep 1, 2024

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 danog changed the title Release mutex if process is killed Add variant of mutex based on flock Sep 2, 2024
@danog
Copy link
Contributor Author

danog commented Sep 2, 2024

Split the new mutex into a separate class.

@trowski trowski mentioned this pull request Dec 6, 2024
@trowski
Copy link
Member

trowski commented Jan 12, 2025

Superseded by #87.

@trowski trowski closed this Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

FileMutex does not release mutex if process is killed

3 participants