.gdk_lock and the GDK locking scheme

Eyal Rozenberg 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 mailing list