tdb API issues

Howard Chu hyc at
Wed Apr 1 19:48:48 GMT 2009

Unfortunately we still have a problem in incorporating tdb into a slapd 
backend - slapd is threaded, and tdb->ecode is shared state. I had intended to 
wrap tdb calls inside a reader/writer lock but if multiple readers encounter 
errors, tdb->ecode will be overwritten and that will make proper error 
handling impossible.

A number of suggestions were made on IRC, but all of them involve fairly 
invasive changes to the tdb code.

1) use thread-specific-data (TSD) for tdb->ecode. This is probably the most 
transparent change, but imposes a direct dependency on pthreads in the tdb 
library. (And it introduces Windows compatibility issues; a different set of 
TSD APIs will be needed for various other platforms as well.)

2) rewrite the tdb APIs to return their actual error code instead of just 0 / 
-1 success/fail status. No platform dependency issues, but a drastic impact on 
the API.

3) introduce a second set of APIs (tdb_foo_r) that parallels the existing API 
but stores the error code in a new function argument. Somewhat less impact on 
the API. (All of the existing APIs would then be reimplemented as wrappers 
around the _r functions.)

All of these choices will require touching all of the tdb source files. Even 
with (3), leaving as much of the exported API unchanged as possible, things 
like the log_fn callback will still need to be changed.

At this point I'm stopped until we decide which way forward.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

More information about the samba-technical mailing list