tdb API issues

Howard Chu hyc at
Fri Apr 3 03:21:19 GMT 2009

Howard Chu wrote:
> Howard Chu wrote:
>>> It might also be possible to have a common virtual address space. To
>>> do that we'd break up the tdb_context structure into per-thread and
>>> per-process parts, and put the mapped pointers in the per-process
>>> part. It would require some thought to make sure this is safe, but at
>>> first glance I think its doable.
>> OK, this sounds like a reasonable avenue to explore. If we also provide some
>> callbacks for creating, locking/unlocking and freeing mutexes then we can
>> explicitly make the relevant parts safe.
> I have a preliminary patch up on

The majority of the patch is purely cosmetic; I added prefixes to all the 
tdb_context member names so that they can all be identified unambiguously. 
(That also makes future global replaces a lot easier...) Then I split the 
tdb_context into a tdb_base_context which stores the main state, and the 
tdb_context which is "per-thread". A thread calls tdb_clone() to get its own 
working copy of a tdb_context, and all of the clones share the original's 
tdb_base_context. In the current setup, the original tdb_context must not be 
closed before any clones. (I guess it would be smarter to allocate the 
tdb_base_context independently, and refcount it.)

I'm not sure yet that I've split things between the base_context and the 
caller context correctly; this is still all a work in progress but I wanted to 
get some early feedback.

MUTEX_LOCK / MUTEX_UNLOCK macros are used where needed. If the caller didn't 
provide a set of mutex methods (via tdb_set_mutex()) then these macros will do 

> the caller must call
> tdb_set_mutex() and provide it a structure which contains a table of mutex
> function pointers. The tdb_set_mutex() function will then create whatever
> locks it needs.
> The trick from here on out is identifying where all the locks need to be inserted.

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

More information about the samba-technical mailing list