Semaphore (sysvsem) support

[dciprian-petrisor]

Hello,

I recently upgraded my project to Symfony 7.3 and encountered an issue due to a new Messenger component middleware they've introduced (not particularly important so I'll skip over it).

The jist is, their middleware uses Semaphore (sysvsem) under the hood to deduplicate messages.

This failed miserably when I deployed to lambda using Bref, as I discovered the PHP compiled in the Docker image was not compiled using --enable-sysvsem.
https://www.php.net/manual/en/sem.installation.php

I was wondering if there is any limitation regarding this with Bref/Lambda or this was just something not taken into consideration.
I searched the issues/PRs in this repo but found no references to sysvsem itself.

As far as I found out, Semaphore support in PHP relies on semget/semop system calls in Linux, so they're just wrappers around that.

Should Bref compile with --enable-sysvsem if there is no issue with this particular mechanism in Lambda?

I used bref/arm-build-php-82:2 to build my image.

[mnapoli]

Hi, this is the first time I hear about that PHP extension indeed, I can confirm it's not in Bref (as the PHP docs mention it's not enabled by default).

Is this PHP extension required for Symfony 7.3?

And separately: would it be even working in the case of distributed workers like on Lambda? I.e. how can multiple workers running on separate machines use a filesystem-based semaphore to coordinate?
I looked at the docs in Symfony (very little content https://symfony.com/doc/current/components/lock.html#semaphorestore) but I think you really don't want to use that driver on Lambda. Instead you might want to use a central system like Redis, the database, or anything that is not local.

[dciprian-petrisor]

According to the table here: https://symfony.com/doc/current/components/lock.html#available-stores the Semaphore store is meant as a "local" locking store, so the use case is a bit different.

I guess it would be useful in some niche situations in Bref, for example if you spawn sub-processes within the Lambda, separate from the main php process (e.g. running a bin/console command asynchronously or similar), where you'd want to use Semphore locks within that Lambda container instance, so no two resources can be accessed at the same time by multiple processes.

To answer your question pertaining to Symfony 7.3 in particular: they've introduced this deduplication middleware in Symfony 7.3 as an enhancement, and the constructor gets triggered by default.
My LOCK_DSN environment variable, used to initialize the default Symfony\Component\Lock\LockFactory instance by Symfony's Lock component , was set to semaphore (which was most likely a default as far as I can tell when I created my project a long long time ago that may or may not have changed).

Everything worked fine in traditional webserver environments in my project (AWS Elastic Beanstalk), but on Lambda it crashed due to the missing compilation flag, hence I decided to raise this feature request.
For the moment I've overwritten the LOCK_DSN for Bref deployments to null which translates to the NullStore option (this is detailed underneath the Available Stores table I've linked above).

Whether it should be enabled, I'm leaving up to you.
If it does not cause any headaches (e.g. image size remains roughly the same, not a lot of changes to introduce besides just enabling when the Bref image is built), it would be good to have it enabled.

If you decide not to, perhaps a disclaimer that it is not supported would be good enough.