In article <[EMAIL PROTECTED]>, marcello <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
