tdb2: check PID if we are holding a lock.
authorRusty Russell <rusty@rustcorp.com.au>
Thu, 24 Mar 2011 01:24:43 +0000 (11:54 +1030)
committerRusty Russell <rusty@rustcorp.com.au>
Thu, 24 Mar 2011 01:24:43 +0000 (11:54 +1030)
commite6862ec8ae269217f3596f5af84747868b983afb
tree863797a5710ceb1898ab402f6c69ef514d35de60
parentf513c5701b184fd1c0a6f03431c7fdda3ab6d2cf
tdb2: check PID if we are holding a lock.

tdb1 has tdb_reopen/tdb_reopen_all, which you are supposed to call
after a fork().  But we can detect PID changes whenever we grab a lock,
which is to say, before we do anything.

We currently assume that pread and pwrite work, so the only problem
with fork() is if we are holding locks and expect them to still be
there in the child.  This is unusual, but most likely caused by a
fork() inside a transaction.  In such cases, allow the child to unlock
without complaint; they can then use the TDB as expected.

Performance before and after shows no measurable speed difference:

Total of 5 runs of tools/speed 100000:
Before:
Adding: 18899ns
Finding: 7040ns
Missing: 5802ns
Traversing: 6466ns
Deleting: 12607ns
Re-adding: 14185ns
Appending: 20770ns
Churning: 93845ns

After:
Adding: 18073ns
Finding: 6795ns
Missing: 5549ns
Traversing: 6333ns
Deleting: 12313ns
Re-adding: 13835ns
Appending: 20343ns
Churning: 92208ns
ccan/tdb2/doc/TDB1_porting.txt
ccan/tdb2/lock.c
ccan/tdb2/private.h
ccan/tdb2/test/run-fork-test.c [new file with mode: 0644]