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
Showing
Please register or sign in to comment