Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.4 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "feature/expand-lockabletrait-api on 7.4".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@chalasr Could you take a quick look at this PR? 🙂

Looks sensible. Can you check if there is some test case covering LockableTrait and, if any, update it according to this change?

Looks sensible. Can you check if there is some test case covering LockableTrait and, if any, update it according to this change?

Hi, after studying the code more thoroughly, I concluded that SemaphoreStore and FlockStore are not designed to be safe in forked processes, as they rely on the state stored in Key internally.

If we apply the change I proposed, there's still an issue where Lock::isAcquired() / SemaphoreStore::exists() returns incorrect results when autoRelease is enabled. Specifically, in the parent process, the Key state will exist (see exists() in SemaphoreStore/FlockStore), even though the actual lock no longer physically exists.

This can be handled fairly simply in FlockStore, but with SemaphoreStore it’s more complicated. The PHP sysvsem extension does not provide any way to check if a semaphore actually exists. Any check would have to be indirect and therefore unreliable.

The only idea I have so far is to use the sysvshm extension, storing semaphore state in shared memory between PHP processes: creating an entry when the semaphore is created, removing it when the semaphore is released, and checking this shared memory to determine semaphore existence. Of course, this solution is not very elegant and adds an additional dependency.

Maybe someone has better suggestions?