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 <ebl...@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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
