On 4/28/23 13:25, Richard W.M. Jones wrote:
On Thu, Apr 27, 2023 at 10:35:30AM -0500, Eric Blake wrote:
> Reviewed-by: Eric Blake <eblake(a)redhat.com>
Thanks, I pushed the two patches as e397f0643..9b5b93a07
About using fcntl locks: it seems troublesome because we'd then need
to have an actual file to lock (even one in /dev/shm). That makes the
implementation significantly more complicated in unexpected ways. I'm
thinking about error handling as we'd need to handle file errors
rather than basically aborting on pthread error as we do now.
(I'm commenting on this side-topic for its own sake, not because I'm
proposing that the code be changed!)
This problem might not be difficult to solve. Where we now call
pthread_rwlock_init(), we could create a temporary file with mkstemp(),
stash the fd, and immediately unlink the file. There are some extra
error modes possible there, but they all could only happen at
initialization.
Then wherever we now call assert() in ACQUIRE_RDLOCK_FOR_CURRENT_SCOPE()
etc, the same kind of assert() should work against fcntl(); should we
abort there, nothing would be left to clean up, as at that point, the
only reference to the inode would exist in the process image. Once the
process disappeared, the filesystem would release the inode.
(Our "cleanup unlock" functions already have their internal asserts;
those would remain necessary for the fcntl flavor too.)
Laszlo