While slowly absorbing sks-keyserver code by browsing mail archives and code, I found this attempt to add DB_INIT_LOCK way back when:
http://lists.gnu.org/archive/html/sks-devel/2004-07/msg00018.html So I added DB_INIT_LOCK, restarted servers, and verified Yup, deadlock still exists, broken. (aside) Well, half broken: the KDB, but not the PTree, database seems okay with DB_INIT_LOCK. The fundamental issue (imho) is that Berkeley DB does locks per page, not locks per record, and so its pretty easy to self-deadlock. Running db_deadlock (as attempted in the link above) is one approach. But there are other approaches as well, including 1) reducing page size to one key per page 2) changing the access to avoid the READ <-> WRITE deadlock by postponing the writes until after the reads are finished and perhaps several other means. (aside) BTW, can someone describe -- even superficially -- what is being attempted with the PTree store? Any details are welcomed, I'm not yet able to read OCAML code well enough to recognize what type of store is being attempted. The PTree deadlock is easily reproduced, and (with db_stat) a detailed deadlock diagnosis could be attempted. Is there interest in adding DB_INIT_LOCK to the PTree store? Has anyone else looked at DB_INIT_LOCK since the link in the archives above? Any historical context is appreciated. 73 de Jeff _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel