Date: Sat, 18 Mar 2023 11:32:37 -0400 (EDT) From: Mouse <mo...@rodents-montreal.org> Message-ID: <202303181532.laa29...@stone.rodents-montreal.org>
| On examination, the manpages available to me (including the one at | http://man.netbsd.org/flock.2) turn out to say nothing to clarify this. The man page (including the one on the web that you referenced) starts out: flock() applies or removes an advisory lock on the file associated with the file descriptor fd. and then lower down, under NOTES: Locks are on files, not file descriptors. That is, file descriptors duplicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. Applying flock() to an already locked (of this kernel file*) file is an attempt to upgrade, or downgrade (including unlock) the file, and would only block on an upgrade attempt if some other file* referencing the same file (ie: the product of a distinct open() etc) is holding a lock that blocks the upgrade. | Is this expected behaviour, or is it a bug? Expected Always been this way. kre