Actually, register_shutdown_function is resistant to fatal error. So the PID check is a bonus for linux user.

But signals don't not trigger it. Same thing for __destruct.

please add a checkbox for writing the documentation PR

should we add a soft suggest on the process component? Of course redis sounds like a good fit, about the drivers would be good to first get the use case right, so could you please provide an explanation like @webmozart does ? 👶

@cordoval The use case is already described in the 2 linked issues.

I think that all drivers will check for pid - isn't it better to have class AbstractLocker which could look like

abstract class AbstractLocker
{
    public function isLocked($name)
    {
        $pid=$this->retrievePid($name);
        // system based check goes here
    }

    abstract function lock($name) {  }

    abstract function unlock($name) {  }

    abstract function retrievePid($name) {  }
}

It should make all drivers more DRY :)

@malarzm Retrieving the PID is only possible when everything is on the same machine. So it does not make sens. More over, I think I will remove this implementation and use flock

I thought retrievePid would be less confusing than getPid ;) I meant use of $pid = file_get_contents($lockFile); for FilesystemLocker in retrievePid function

@malarzm what @lyrixx meant is that a locking mechanism which supports locking accross several servers (when you have 2 workers for instance) would not be based on checking a PID.

Ah right, sorry, I think I need more sleep

#3586 talks about a doctrine driver so i guess that is a request.

Actually, I will remove the interface. And so I will not implement doctrine or redis. Distributed lock is really too hard, with too many edge case. So We will keep something very simple, that work only for one server.

( @romainneutron found this gist for windows)

should we add a soft suggest on the process component?

@lyrixx keep the interface maybe, to let others provide their own implementations (not in the core)?

Hello. I have updated the code. All code came from @romainneutron ;)

Now, we support only one kind of driver (file-system), So there is no need for an interface. It is done on purpose. Using a lock feature in a network is a nightmare. So we do not want to support it at all.

ping @dunglas

I've some concerns about this implementation:

• it doesn't fit my use case. I need blocking locks to allow a command waiting the end of a previous one before running. Here, the non blocking mode is hardcoded (and according to the PHP doc, this mode is not supported on Windows)
• I think it's not the responsibility of this class to kill processes. Let the developer - or the OS - doing that. And what if the killed process is a daemon or something like that? Locks aren't necessary pid files.
• The interface was a good idea IMO (and I'll probably need "network" locks soon). A memcache lock should not be too hard to implement (even outside of core as already said).

What about

interface Lock
{
    public function lock($blocking = true);
    public function unlock();
    public function isLocked();
}

it doesn't fit my use case. I need blocking locks to allow a command waiting the end of a previous one before running. Here, the non blocking mode is hardcoded (and according to the PHP doc, this mode is not supported on Windows)

Why not ;)

I think it's not the responsibility of this class to kill processes. Let the developer - or the OS - doing that. And what if the killed process is a daemon or something like that? Locks aren't necessary pid files.

We kill nothing.

The interface was a good idea IMO (and I'll probably need "network" locks soon). A memcache lock should not be too hard to implement (even outside of core as already said).

Actually, It's VERY VERY hard to implement. What if your command segfault ? nobody will release the lock... The only almost working implementation implies heart beat... And this is hard to implements. See the "warning" section I added to the LockHelper class

Then, If you need a custom lockHelper, just create a new one. There is no need to use an interface for that ;)

@Tobion Thanks for the review. I hope it's ok now ;)

Travis and fabbot are of. shippable no and I don't know why. ping @fabpot.

forget about shippable, it was just a test

So it's ready for merge

👍

Just curious what you folks think about getting rid of the file locks and using port bindings, like it's described here?

Thank you @lyrixx.

@rybakit your idea is interesting, but I'm not fan of it because

• the port could be already used by another application on production server (and not on your local machine)
• I don't know if it work well on windows
• It takes a port.
• It's a bit a hack, port did not designed for that, where flock are.

Hi guys. I have a similar project already (https://github.com/iainp999/lockman - approach is slightly different, happy for feedback) but would be interested in contributing to a more generic solution for SF2.

@iainp999 We explicitly rejected adding distributed locking in core. People needing such feature would then need to use a library providing such feature (either your library, or one of the others available on Packagist)

@stof oh ok, cool

Could you please @lyrixx provide an interface for the LockHandler class?
It would be useful to enhance this class by using wrappers.. but this means having an interface to implement.

@temple We do not provide an interface on purpose. It works only on one single server.

If you want something more sophisticated, please use the Lock component instead.

Are you referring this one, @lyrixx ?
http://symfony.com/blog/new-in-symfony-3-3-lock-component

yes.

Thank you very much!