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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
