this is a demonstration of an idea for handling locks in ctdb.

The problem we have is this:

  - we want the client smbd processes to be able to 'shortcut' access
    to the ltdb, by directly accessing the ltdb, and if the header of
    the record shows we are the dmaster then process immediately, with
    no overhead of talking across the unix domain socket

  - a client doing a shortcut will use tdb_chainlock() to lock the
    record while processing

  - we want the main ctdb daemon to be able to set locks on the
    record, and when those locks collide with a 'shortcut' fcntl lock,
    we want the ctdb daemon to keep processing other operations

  - we don't want to have to send a message from a smbd client to the
    ctdbd each time it releases a lock

The solution is shown in this example. Note that the expensive fork()
and blocking lock is only paid in case of contention, so in the median
case I think this is zero cost.

(This used to be ctdb commit a3248c3e2b740cd2403acffd3c1f6a33dca0ea03)

1 files changed, 1 insertions, 0 deletions

diff --git a/ctdb/config.mk b/ctdb/config.mk
index 0e0629bfb1f..a16b7b29919 100644
--- a/ctdb/config.mk
+++ b/ctdb/config.mk
@@ -15,6 +15,7 @@ OBJ_FILES = \
 
 ##################
 [SUBSYSTEM::ctdb]
+INIT_FUNCTION = server_service_ctdbd_init
 OBJ_FILES = \
 		ctdb_cluster.o \
 		common/ctdb.o \