Product
Introducing License Enforcement in Socket
Ensure open-source compliance with Socket’s License Enforcement Beta. Set up your License Policy and secure your software!
Basic inter-process locks
The zc.lockfile package provides a basic portable implementation of interprocess locks using lock files. The purpose if not specifically to lock files, but to simply provide locks with an implementation based on file-locking primitives. Of course, these locks could be used to mediate access to other files. For example, the ZODB file storage implementation uses file locks to mediate access to file-storage database files. The database files and lock file files are separate files.
.. contents::
Detailed Documentation
The ZODB lock_file module provides support for creating file system locks. These are locks that are implemented with lock files and OS-provided locking facilities. To create a lock, instantiate a LockFile object with a file name:
>>> import zc.lockfile
>>> lock = zc.lockfile.LockFile('lock')
If we try to lock the same name, we'll get a lock error:
>>> import zope.testing.loggingsupport
>>> handler = zope.testing.loggingsupport.InstalledHandler('zc.lockfile')
>>> try:
... zc.lockfile.LockFile('lock')
... except zc.lockfile.LockError:
... print("Can't lock file")
Can't lock file
.. We don't log failure to acquire.
>>> for record in handler.records: # doctest: +ELLIPSIS
... print(record.levelname+' '+record.getMessage())
To release the lock, use it's close method:
>>> lock.close()
The lock file is not removed. It is left behind:
>>> import os
>>> os.path.exists('lock')
True
Of course, now that we've released the lock, we can create it again:
>>> lock = zc.lockfile.LockFile('lock')
>>> lock.close()
.. Cleanup
>>> import os
>>> os.remove('lock')
In a container environment (e.g. Docker), the PID is typically always identical even if multiple containers are running under the same operating system instance.
Clearly, inspecting lock files doesn't then help much in debugging. To identify the container which created the lock file, we need information about the container in the lock file. Since Docker uses the container identifier or name as the hostname, this information can be stored in the lock file in addition to or instead of the PID.
Use the content_template
keyword argument to LockFile
to specify a
custom lock file content format:
>>> lock = zc.lockfile.LockFile('lock', content_template='{pid};{hostname}')
>>> lock.close()
If you now inspected the lock file, you would see e.g.:
$ cat lock
123;myhostname
Change History
python_requires
to setup.py
to prevent installing on not
supported old Python versions.Add support for Python 3.9, 3.10, 3.11.
Drop support for Python 2.7, 3.5, 3.6.
Drop support for deprecated python setup.py test
.
Extracted new SimpleLockFile
that removes implicit behavior
writing to the lock file, and instead allows a subclass to define
that behavior.
(#15 <https://github.com/zopefoundation/zc.lockfile/issues/15>
_)
SimpleLockFile
and thus LockFile
are now new-style classes.
Any clients relying on LockFile
being an old-style class will
need to be adapted.
Drop support for Python 3.4.
Add support for Python 3.8b3.
Claim support for Python 3.6 and 3.7.
Drop Python 2.6 and 3.3.
Stop logging failure to acquire locks. Clients can do that if they wish.
Claim support for Python 3.4 and 3.5.
Drop Python 3.2 support because pip no longer supports it.
Added the ability to include the hostname in the lock file content.
Code and ReST markup cosmetics. [alecghica]
Added Trove classifiers and made setup.py zest.releaser friendly.
Added Python 3.2, 3.3 and PyPy 1.9 support.
Removed Python 2.4 and Python 2.5 support.
Fixed: when there was lock contention, the pid in the lock file was lost.
Thanks to Daniel Moisset reporting the problem and providing a fix with tests.
Added test extra to declare test dependency on zope.testing
.
Using Python's doctest
module instead of depreacted
zope.testing.doctest
.
FAQs
Basic inter-process locks
We found that zc.lockfile demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Product
Ensure open-source compliance with Socket’s License Enforcement Beta. Set up your License Policy and secure your software!
Product
We're launching a new set of license analysis and compliance features for analyzing, managing, and complying with licenses across a range of supported languages and ecosystems.
Product
We're excited to introduce Socket Optimize, a powerful CLI command to secure open source dependencies with tested, optimized package overrides.