File IO with select?

Donn Cave donn at u.washington.edu
Wed Jul 12 12:32:09 EDT 2000


Quoth Jared Lee Peterson <jared at tgflinux.com>:
| I am trying to syncronize two clients that are accessing the same file.
| One client spawns the other and then needs to wait until process two
| writes to the file before it can then read from it.  I am trying to use
| select() for this but I am not having much luck.  So I guess that my
| question would be whether or not I can use select() for this or not.  If
| so could someone offer some guidance ... if not could someone offer
| another suggestion.  Thanks a lot

Select() is not the answer.  You need a filesystem lock.  I'd look
at fcntl.lockf().  Like select(), this function operates on an integer
file descriptor --

    fd = posix.open(file, posix.O_RDWR)   # open file
    fcntl.lockf(fd, fcntl.LOCK_EX)        # lock
    fcntl.lockf(fd, fcntl.LOCK_UN)        # unlock, or
    posix.close(fd)                       # unlock

The cooperating processes must both lock the file, lockf() is where
they interlock.

Don't use buffered I/O.  If you must use a Python file object,
turn off its buffering or use flush() at strategic points.
Same as with select(), the system doesn't work if the processes
don't really write their data out.

To go on to excruciating detail, there are two different kinds of
filesystem lock on some UNIX platforms.  The lock supported by the
fcntl() and lockf() functions is pretty much universal, and since
BSD 4.2, Berkeley platforms have had an flock() that's a little
different.  Some misguided attempts to support Berkeley compatibility
support flock() as a way to call lockf(), but the real flock()
doesn't interoperate with lockf(), applies only to local files
(not remote network mounted) and is somewhat more reliable.  The
flags I use up there with lockf() are really the flags for flock(),
that's how it works in Python.

With fcntl/lockf, if the same file is open on more than one unit,
the first unit to close releases the lock.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list