tdb API issues

[Howard Chu]

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.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/