.gdk_lock and the GDK locking scheme
E.Rozenberg at cwi.nl
Mon Nov 28 18:46:09 CET 2016
I used to think .gdk_lock was used by mserver the same way Linux daemons
use lock files - the filesystem enforces serialization, so if you do:
1. if (lock file present) then locking failed
2. create the lock file
3. if (creation failed) then locking failed
4. locking successful
that's a valid non-blocking locking procedure.
However, it appears that:
* .gdk_lock is not always empty, and can have text such as
USR=12096163 PID=5844 TIME=Thu Nov 24 15:35:08 2016 @ LOGON
USR=12096163 PID=5844 TIME=Thu Nov 24 15:42:26 2016 @ LOGOFF
* If .gdk_lock is not always created on DB startup, nor deleted on shutdown.
* The locking using .gdk_lock is actually an flock() on its 5th byte
(offset 4) and never any other one.
* The GDKunlockhome() file will cause a second file descriptor opening
in addition to GDKlockfile
So I'm a bit confused about the locking scheme. Help?
More information about the developers-list