On Thu, 18 Oct 2012 14:44:27 +0100, andrea crotti wrote: > Uhh I see thanks, I guess I'll use the good-old .lock file (even if it > might have some problems too).
In which case, you don't see. A lock file is also advisory, i.e. it only affects applications which explicitly check for a lock file. Historically, the advantage of lock files was that they worked on NFS implementations which didn't implement locking (it's a long-standing Unix joke that "NFS" stands for "Not a FileSystem", because it failed to conform to established filesystem semantics). Nowadays, NFS implementations which don't support locking are sufficiently rare that they can safely be ignored. So lock files don't offer any advantages, and one fairly obvious disadvantage (the possibility of a "stale" lock file if the program terminates unexpectedly without removing the lock file). For any form of advisory locking, the one thing which matters is that all progams which access the file agree on the mechanism used, i.e. whether to use lockf(), fcntl(), flock() (locks created by one mechanism may or may not be recognised by the others), or lock files, and in the case of lock files, the naming convention which is used. If the file is specific to a particular program, and you just need to protect against multiple instances of that program, you can use whichever mechanism you wish, and would be strongly advised to use kernel locks (fcntl() is the most portable, followed by lockf(); flock() is a BSD-ism). -- http://mail.python.org/mailman/listinfo/python-list
