[Bug 2031277] New: Review Request: python-flufl-lock - NFS-safe file locking with timeouts for POSIX and Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=2031277

            Bug ID: 2031277
           Summary: Review Request: python-flufl-lock - NFS-safe file
                    locking with timeouts for POSIX and Windows
           Product: Fedora
           Version: rawhide
          Hardware: All
                OS: Linux
            Status: NEW
         Component: Package Review
          Severity: medium
          Priority: medium
          Assignee: nobody@xxxxxxxxxxxxxxxxx
          Reporter: michel@xxxxxxxxxxxxxxx
        QA Contact: extras-qa@xxxxxxxxxxxxxxxxx
                CC: package-review@xxxxxxxxxxxxxxxxxxxxxxx
  Target Milestone: ---
    Classification: Fedora



Spec URL: https://salimma.fedorapeople.org/specs/python/python-flufl-lock.spec
SRPM URL:
https://salimma.fedorapeople.org/specs/python/python-flufl-lock-6.0-1.fc35.src.rpm
Description: 
NFS-safe file locking with timeouts for POSIX and Windows.

The flufl.lock library provides an NFS-safe file-based locking algorithm
influenced by the GNU/Linux open(2) manpage, under the description of the
O_EXCL
option.

    […] O_EXCL is broken on NFS file systems, programs which rely on it for
    performing locking tasks will contain a race condition. The solution for
    performing atomic file locking using a lockfile is to create a unique file
    on the same fs (e.g., incorporating hostname and pid), use link(2) to make
a
    link to the lockfile. If link() returns 0, the lock is successful.
    Otherwise, use stat(2) on the unique file to check if its link count has
    increased to 2, in which case the lock is also successful.

The assumption made here is that there will be no outside interference, e.g. no
agent external to this code will ever link() to the specific lock files used.

Lock objects support lock-breaking so that you can’t wedge a process forever.
This is especially helpful in a web environment, but may not be appropriate for
all applications.

Locks have a lifetime, which is the maximum length of time the process expects
to retain the lock. It is important to pick a good number here because other
processes will not break an existing lock until the expected lifetime has
expired. Too long and other processes will hang; too short and you’ll end up
trampling on existing process locks – and possibly corrupting data. In a
distributed (NFS) environment, you also need to make sure that your clocks are
properly synchronized.

Fedora Account System Username: salimma


-- 
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031277
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux