Что: 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.
Даже Поттеринг пишет что всё ужасно.
Сгенерирован: SGBlog 0.34.0