Re: [fcntl]how to lock a file

In article <e1gf6o$74h$1@emma.aioe.org>, marcello <marcs2006@gmail.com>
wrote:

> Carl J. Van Arsdall wrote:
> > [...]
> >
> > If you end up having problems working with the python fcntl module let
> > me know your configuration I'd be interested to see if anyone else had
> > similar problems to me.
>
>
> Python 2.2.3 (#1, Aug 8 2003, 08:44:02)
> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] on linux2
> kernel 2.4.21-4.0.1.ELsmp
> glibc-2.3.2-95.6
>
>
>
> What else can i add?

Maybe something about the problem?

There are four functions in that module - fcntl, flock,
ioctl, lockf. Which one were you using? What were you
trying to do with it?

Did it raise an exception? Returned but didn't effectively
interlock against other processes -- on the same host, on
other hosts? Failed to return when the file should have
been OK to lock?

Is it possible that locks would work fine in a test program,
but fail in your application due to brain damaged POSIX
filesystem locking semantics?

We can start with stuff you probably already know.

- The Berkeley flock(2) function is great but is not
  supported by NFS.

- fcntl(2) F_SETLK etc. are supported by NFS, but have
  extremely inconvenient semantics, part of the POSIX
  1003.1 specifications, particularly the part about losing
  a lock on ANY close(), even if the file descriptor remains
  open for fcntl(2)'s caller.

- lockf(3) is fcntl(2).

- Some platforms provide an flock() that is actually
  fcntl(2), can't think of the right words to express how
  deplorable that practice is.

- On the rare platform that doesn't do this - where they
  are honest enough to just admit that they don't support
  flock() - Python implements fcntl.flock() with fcntl(2),
  I guess on the theory that you can't have enough brain
  damage. The worst case would be if Python's configure
  missed a bona fide flock(2), which is unlikely but may
  be worth checking if you use flock(2) for a reason.

Donn Cave, donn@u.washington.edu
Received on Sun Apr 30 22:52:14 2006