[Python-Dev] Does Python need a file locking module (slightly higher level)?

skip at pobox.com skip at pobox.com
Fri Oct 26 22:10:18 CEST 2007


    Barry> I don't think any one solution will work for everybody.  I'm not
    Barry> even sure we can define a common API a la the DBAPI, but if
    Barry> something were to make it into the standard distribution, that's
    Barry> the direction I'd go in.

I've been working on a lockfile module the past few days on the train.  I
have something that passes a boatload of doctest test cases on my Mac, works
for threads as well as processes (acquire the lock in thread one, then block
in thread two until thread one releases the lock).  The Unix version relies
on the atomic nature of the link(2) system call.  The Windows version (not
yet tested on that platform) relies on mkdir(2) being atomic.  (I think it
is.)  In theory, I suppose the mkdir version will work for both platforms,
so it's possible that you could have file locking between Windows and Unix
should you want it.

The current implementation provides a FileLock class with these methods:

    acquire
    release
    is_locked
    break_lock
    __enter__
    __exit__

The acquire method takes an optional timeout parameter (None => wait
forever, +ive value => block for awhile, zero or -ive => give up
immediately).  The others all take no arguments.  I'm working on ReST
documentation now and hope to have that finished over the weekend.  After
that I'll write a simple setup.py, toss it out on PyPI, then announce it
more broadly.  If anyone would like to try it out and/or review the code
sooner (especially if you have access to Windows) let me know.  I'll shoot
you a copy as it currently exists.

The API and almost all test cases are defined in a _FileLock base class.
You could (in theory at least) subclass it to provide locking through some
other shared resource like a database and not have to write and or many
other test cases.

Skip


More information about the Python-Dev mailing list