Что: c316e72d5489cc61261765b5b74d3f169e45cc21
Когда: 2022-01-10 17:35:09+03:00
------------------------------------------------------------------------
Темы: bsd hate systemd
------------------------------------------------------------------------
Идиотизм lock-ов SysV/POSIX

https://gavv.github.io/articles/file-locks/
https://www.freebsd.org/cgi/man.cgi?query=fcntl&sektion=2
https://lwn.net/Articles/586904/
https://go.dev/src/cmd/go/internal/lockedfile/internal/filelock/filelock_fcntl.go
https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html
https://apenwarr.ca/log/20101213
http://0pointer.net/blog/projects/locking.html
Есть BSD-style lock-и для файлов, есть SysV/POSIX fcntl/flock.
С первыми всё просто, тривиально, надёжно, легко и понятно.
Со вторыми написано хорошо в FreeBSD man-е для fcntl:

    This interface follows the completely stupid semantics of System V and
    IEEE Std 1003.1-1988 (“POSIX.1”) that require that all locks associated
    with a file for a given process are removed when any file descriptor for
    that file is closed by that process.  This semantic means that
    applications must be aware of any files that a subroutine library may
    access.  For example if an application for updating the password file
    locks the password file database while making the update, and then calls
    getpwnam(3) to retrieve a record, the lock will be lost because
    getpwnam(3) opens, reads, and closes the password database.  The database
    close will release all locks that the process has associated with the
    database, even if the library routine never requested a lock on the
    database.  Another minor semantic problem with this interface is that
    locks are not inherited by a child process created using the fork(2)
    system call.  The flock(2) interface has much more rational last close
    semantics and allows locks to be inherited by child processes.  The
    flock(2) system call is recommended for applications that want to ensure
    the integrity of their locks when using library routines or wish to pass
    locks to their children.

В статье с LWN-а:

    More troublingly, the standard states that all locks held by a
    process are dropped any time the process closes any file descriptor
    that corresponds to the locked file, even if those locks were made
    using a still-open file descriptor. It is this detail that catches
    most programmers by surprise as it requires that a program take
    extra care not to close a file descriptor until it is certain that
    locks held on that file are able to be dropped.

Похоже что в AIX и Solaris (но не Illumos) BSD flock-ов нет, поэтому в
Go для работы с ними написана обёртка над POSIX lock-ами, занимающая
несколько экранов кода, как раз для отслеживания всех этих привязок к
инодам.

Кирк МакКузик говорит что во время стандартизации lock-ов всем было
просто плевать, поэтому добавили как уже было в SysV.

Даже Поттеринг пишет что всё ужасно.

------------------------------------------------------------------------
оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%98%D0%B4%D0%B8%D0%BE%D1%82%D0%B8%D0%B7%D0%BC%20lock-%D0%BE%D0%B2%20SysV%2FPOSIX%20%28c316e72d5489cc61261765b5b74d3f169e45cc21%29

------------------------------------------------------------------------
Сгенерирован: SGBlog 0.34.0