GNOME Bugzilla – Bug 307131
file locking wrappers for GLib
Last modified: 2018-05-24 10:35:52 UTC
Wrappers for file locking would fit nicely into GLib. Many of the GNOME libraries have essentially duplicated code snippets for this, and especially as they are ported to Win32, it's tiresome to do the same porting several times. IMHO it would be enough, at least as a start, to just have API to lock the whole of the file, test if a file is locked, and unlock. The locking API could have parameters to specify whether to retry the lock, how many times to retry, and with what interval (possibly random). One problematic issue would be what behaviour to specify or guarantee in multiple thread cases. If I unerstand the lockf() spcification correctly, locks are per-thread. The Win32 LockFile() documentation on the other hand talks only about processes.
File descriptors locked using lockf(2) are not inherited by child processes; for that, flock(2) should be used - but flock(2) doesn't behave well over NFS-mounted volumes, so fcntl(2) should be used instead. Most of the times, lockf(2) is enough on POSIX-compliant systems, though. If we want a simple GLib wrapper for file locking, I'd say we should stick to lockf(2) on *nix.
Created attachment 51224 [details] simple lock API simple API for file locking. you create a GLockedFile object, and then lock/unlock it. freeing a GLockedFile will result in removing any lock. locking mechanism: write and read/write will use lockf(); read (if implemented) should use fcntl().
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/33.