3 ms·

I just recently discovered fcntl for creating file-based locks (and the python function which calls it, fcntl.flock) and was pretty excited. It seems like a mu

I just recently discovered fcntl for creating file-based locks (and the python function which calls it, fcntl.flock) and was pretty excited. It seems like a much safer way to do multi-process locking than creating lock files on my own

carey 17y ago
There is a catch, though; if you have the same file open multiple times, even with different names, then closing one file descriptor will release all locks on that file in the same process, even in different threads. SQLite goes to great lengths to work around this. See: http://www.google.com/search?q=broken+by+design+site:sqlite.org http://www.google.com/search?q=broken+by+design+site:sqlite....
- cperciva 17y ago
  There is a catch, though; if you have the same file open multiple times, even with different names, then closing one file descriptor will release all locks on that file in the same process, even in different threads. It's even worse than that. A lock is released as soon as any of its owning processes closes any descriptor to that file. As a result, if a child forks and exits, the parent no longer holds any locks...
  - JeffJenkins 17y ago
    That's definitely worth keeping in mind! Does that apply to sibling processes as well (like two apache child processes)?
peterwwillis 17y ago
IIRC opening a file and using link() is about the only portable atomic method of file locking. Works on NFS and pretty much any UNIX. There may have been some other trick to making it work right on NFS but if you're going that far you may just need a lock manager.
- briansmith 17y ago
  As long as you are using NFSv4 with properly-configured, non-buggy clients and servers, fcntl-based locking will work correctly.
  - peterwwillis 17y ago
    I agree. If only every client were capable of properly-configured non-buggy NFSv4... Hence why I say the "portable" method is with link(). There are a lot better solutions if you don't have to support crappy clients.

carey 17y ago

There is a catch, though; if you have the same file open multiple times, even with different names, then closing one file descriptor will release all locks on that file in the same process, even in different threads. SQLite goes to great lengths to work around this. See: http://www.google.com/search?q=broken+by+design+site:sqlite.org http://www.google.com/search?q=broken+by+design+site:sqlite....

cperciva 17y ago
There is a catch, though; if you have the same file open multiple times, even with different names, then closing one file descriptor will release all locks on that file in the same process, even in different threads. It's even worse than that. A lock is released as soon as any of its owning processes closes any descriptor to that file. As a result, if a child forks and exits, the parent no longer holds any locks...
- JeffJenkins 17y ago
  That's definitely worth keeping in mind! Does that apply to sibling processes as well (like two apache child processes)?

peterwwillis 17y ago

IIRC opening a file and using link() is about the only portable atomic method of file locking. Works on NFS and pretty much any UNIX. There may have been some other trick to making it work right on NFS but if you're going that far you may just need a lock manager.

briansmith 17y ago
As long as you are using NFSv4 with properly-configured, non-buggy clients and servers, fcntl-based locking will work correctly.
- peterwwillis 17y ago
  I agree. If only every client were capable of properly-configured non-buggy NFSv4... Hence why I say the "portable" method is with link(). There are a lot better solutions if you don't have to support crappy clients.