Hacker News Reader

Comment by JeffJenkins | Hacker News Reader

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

View on HN

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....

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...

That's definitely worth keeping in mind! Does that apply to sibling processes as well (like two apache child processes)?

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.

As long as you are using NFSv4 with properly-configured, non-buggy clients and servers, fcntl-based locking will work correctly.

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.

Reply on news.ycombinator.com