In article <e1**********@emma.aioe.org>, marcello <ma*******@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,
do**@u.washington.edu